Software vulnerabilities: Bugs v Flaws lessons from June
Lessons from some of June's vulnerabilities
By Industry Insight | Published: 16:37, 30 July 2013
When it comes to software defects, we generally categorise vulnerabilities to be as the result of a bug or a flaw. A bug is generally caused by a failure in implementation, so the design could be perfectly fine, but some aspect of the implementation fails and security vulnerabilities result. A flaw, on the other hand, is a design that creates a vulnerability, and the only way to fix it is to change the architecture and re-implement according to the corrected design.
For developers this is very important, because finding and fixing bugs is completely different from finding and fixing flaws—but attackers don’t care. Attackers exploit bugs and flaws equally well.
In this piece, I will take a look at some of the most significant software security defects that have hit the news over the past weeks, and determine whether they have been the result of a software bug, or a software flaw.
BUG: Spotify Unicode Usernames: Account Takeover
Spotify recently posted a blog about one of the core features of their software which, whilst it is something they’re very proud of, has also been the source of “great pain” for them over the years - their Unicode usernames.
Spotify has done a real service to the Internet community by posting such a clear and detailed explanation of how users were leveraging Unicode user names to take over accounts, and we can see that this incident boiled down to several bugs creating a perfect storm. Their design is sound: allow Unicode characters so that BjÃ¸rn and æ–°ç±³can have user names that are meaningful in their native languages.
They relied, however, on a username canonicalisation function that let them down. Canonicalization is the process of having one true representation of something. E.g., if you enter your user name as SurfDude, surfdude, or SURFDUDE, it gets turned into one, well-known representation (“surfdude” all lower case). The function they had was clever enough to turn letters like Ã˜ and Ã¸ to the same letter (Ã¸) and to be idempotent. That is, no matter how many times you called the canonicalise function, you would end up with exactly one true form.
The bug was that the implementation was only idempotent for some Unicode characters, but not all. They did not realise that there were some inputs that were legitimate Unicode characters that would be handled badly. For example, the letter á´®, when canonicalized, would become ‘B’. And later, B could be canonicalized to ‘b’. The ultimate result is that a few lines of code needed to be inserted to ensure that bad characters were excluded. Given that, the problem went away. The key way we recognise this as a bug and not a flaw is the fact that their design remained unchanged.
Flaw: Webcam Unauthorised Access via Flash
On the same day that we saw Spotify blogging about security vulnerabilities in its own software, news broke about the Adobe Flash flaw that allows hijackers to seize control of user’s webcams.
Flash’s graphical strengths are a security weakness. In this instance, a dialog box that asks “do you want to grant access to your camera” can be obscured by an attacker’s graphics, as shown below. This is very similar to an attack called “click jacking” where innocent users are tricked into clicking on certain places in a web page by overlaying something else over the top of it. The user thinks they are clicking on one thing, but the click is actually handled by something else. In this case, the user thinks they are clicking “Yes” to “Do you want to win a million dollars”, but in fact they are clicking “Authorise” on the button to turn on their camera.
This is a flaw in the design of Flash. The dialog that asks you for permission needs to be “out of band”. That is, it cannot appear within the same boundary and controls as the potentially malicious code. Ideally the dialog should be modal, above all other graphics, and displayed outside the boundary of the flash object. This will be a significant change to the operation of the plugin, and it will affect the implementation on all the different browsers and architectures. Thus, it is a flaw.
 Graphic from http://habrahabr.ru/post/182706/
Flaw and Bug: Cracking iOS Personal Hotspot Passwords
Another software security issue emerged this month, but this time from Apple, who had unwittingly put users at risk of man-in-the-middle attacks and data theft when using their iPhones as mobile hotspots.
Apple’s mistake in randomly selecting hotspot passwords has elements of both bugs and flaws. The design is essentially hopeless because it relies entirely on lists of words and a few random numbers. Even perfectly implemented, there are only 18 million combinations. That might be too many for an iPhone to brute force, but any reasonable laptop can do it while you wait. There was an implementation bug, too, which caused the choice of words to be biased towards a small set.
Even without the bug, the design is based on a small set of words and a few random numbers. It produces entirely too few possible passwords. They could keep their small dictionary, but chose an implementation closer to “correct horse battery staple” (http://xkcd.com/936/). Choose 3 words from the dictionary at random, and insert 2 random digits between them. Thus passwords like “head7coal2pool” would be produced.
There would be around 624 Billion possibilities, making it far harder to brute force, but fairly easy to remember. They would still have to investigate their implementation bug to ensure that they are drawing random words truly randomly and without bias, but the flaw of the password choice is the most important failure to fix.
Posted by Paco Hope, Principal Consultant Cigital, Inc.
Paco leads Cigital’s efforts in online gaming security, including random number generator (RNG) certification and the SafeBetTM online gaming security certification. He co-authored the Web Security Testing Cookbook and Mastering FreeBSD and OpenBSD Security, (O’Reilly and Associates).