Once I stated the title I immediately realized that there are many distinct dimensions having their own «bottoms» and «ups». So I must specify. The «bottom» is a set of elementary data manipulation operations available to you as a programmer or a data security specialist (although it is often the same «you»). The «top» is a transitive closure of this set. The set of operations available for a user is rather close to the «top», and mapping them into the basic data handling operations constitutes the essence of the programmer's job. The «bottom-up» approach to data security is a job of defining all the necessary data access rules in terms of the basic data handling operations — you apply certain restrictions to various data elements and they affect the data system overall behavior, namely data accessibility in the high-level terms used by the end users. The most elaborated text-book example of this approach is SQL — it gives you very low-level security bricks to build a custom building without specifying explicitly this building emergent properties.
Read more →

This is not only an SQL's problem, I am going talk about, this is a pretty general problem of all complex systems dealing with user permissions, however SQL constitutes the best possible illustration to the issue.The principal source of all evil is the generalized security policies, policies trying to cover the entire space of user actions by being formulated in basic general terms.
Read more →

A russian researcher Maxim Andreev (Максим Андреев) from cloud.mail.ru has discovered recently an appaling (and also embarrassing) security hole in FFmpeg (a popular open source video/audio processing library (yes, thanks god(s) it is open source)). The vulnerability may potentially lead to SSRF and local file read (which in turn may be pretty devastating). To put your computer at risk it is sufficient to keep it connected to the internet while processing with FFmpeg a specially crafted .mpeg file. So the attack may be aimed at servers and desktops as well, and it is important for the desktop users to know that nearly all GUI-oriented filemanagers and file-dialogs do run without a user's consent ALL the .mpeg files in the scope through the thumbnail creation procedure which is often built around FFmpeg library. Oh, my dear «user-friendliness»! Do you feel how problems are piling up?

The vulnerability is based upon the HLS (HTTP live streaming) feature (thanks to the reported vulnerability I now know what is live streaming — what a useful feature it must be). The core of the vulnerability is (as it happened many times before) a masquerade of filetypes multiplied by the stupidity of the modern days programmers. Effectively the worm is a PLAYLIST file masquerading as an ordinary .mpeg. And FFmpeg is programmed to process them «transparently» i.e. HIDE the distinction between them from the user. The playlist file is allowed to prescribe HTTP requeststs (supposedly to retrieve a file to play) and FFmpeg is eager to obey! Thus, FFmpeg being entitled to the access privileges of its caller SILENTLY sends HTTP-requests (full of potentially sensitive data) to an arbitrary HTTP-server in the internet.

Well done FFmpeg! well done!
And I personally send many non-sarcastic thanks to Maxim Andreev.

By the way, Maxim in his original article on habrahabr.ru describes some interesting practical exploits of the vulnerability, if anyone is interested, i can translate his article to English and post it here.

...and remember all vulnerabilities are deliberately created by someone.

This is a real life story. We were building an enterprise with micro-payments involved and stuff. We needed a terminal/kiosk network, and this task was bound to be outsourced. So my boss had found a company XYZ that offers ready-made solutions, and he asked me to investigate their offer. I returned to him with my verdict:
— we can't use this XYZ service, because they require our users to submit their passwords to XYZ and then XYZ logs into our system on user's behalf. This is plain out wrong, and should not be implemented ever.
He argued on the basis «a well established company can not possibly sell us junk» — so stunningly true! yeah! So he decided to carry out his own investigation.

A few days later he informed me of his decision:
— I have presented the XYZ's offer to a computer security specialist N. He advised us against using the XYZ's services because they do not employ cryptography.

So the story has ended quite happily. Thanks to the magic of the «cryptography».

Do you really, i mean really, believe that computers are afraid of capital letters? and punctuation? Don't tell me that you want to scare off people, not computers, it would be even more ridiculous, given a second thought.

How would you feel if a service provider asks you: «please include at least three capital letters, seven underscores, and a number thirteen in your password»? — weird? You better adjust your attitude. The first ingredient is already required by some, more to follow soon.

Seriously, have you ever tried to think why all those «password choosing» policies are so ridiculous and stupid, are they as beneficial as people believe?

The serious answer to the question is given in my new paper on the password authentication: arxiv.org/abs/1505.05090 and its summary is as follows: «The password policies are futile, because they have no formal mathematical foundation at all, and this is why they are all as ridiculous as homeopathy».

Here i want to present some fun aspects of the problem.

The two most prominent protagonists of computer security MS and Google directly contradict each other:

DO NOT USE:
Common letter-to-symbol conversions, such as changing «o» to «0».
USE:
similar looking substitutions, such as the number zero for the letter 'O'
No one notice. These both password creation policies are equally respected. Who are we to doubt the Wisdom of the Titans!?

Also, the Titans teach us that there is an inherent contradiction between security and memorability. Of course the Titans do not condescend to proving their claims. We are supposed to make a leap of faith. I don't have faith, i need a proof, or at least some evidence supporting the claim. Here is the claim:

Human memory is limited and therefore users cannot remember secure passwords.
Call me when you find any evidence of that.