Geekonomics - Criticism of Chapter 6 on opensource software

Second of the series of articles inspired by David Rice's Geekonomics.

I am not totally satisfied with David Rice's take on opensource software in his Chapter 6: Open Source Software: Free, But at What Cost?

While he definitely has good points as a whole, and while I see his description of some of the hidden defects of opensource projects as accurate, I am sad that he forgets to mention about real big companies taking a part in opensource developments. Companies like IBM, Sun (now Oracle) or Apple all make some opensource developments, and you cannot tell that they act as beginners or non-professionals in their development methodologies.

And I am also a little surprised to see that the author compares opensource development projects to an "idealized" proprietary development project. For instance, he says it is possible that a part of an opensource software will go unmaintained because of a lack of interested people and forgets to say that even in big proprietary developments, such things also happen, because of mediocre management or because of periods of deep stress.

I would say that Chapter 6 holds some good points but my conclusion be:

• Opensource software is not a radical change from proprietary software in the methodologies.
• Opensource software is not radically more secure or of better quality than proprietary software by essence.
• The "given enough eyeballs, all bugs are shallow" argument is valid, and those opensource software which have a high number of both users and developers actually get an improvement of their quality and security.
  

Geekonomics - Reasons for the States NOT to fix software quality problems

First of the series of articles inspired by David Rice's Geekonomics.

As an introduction I would like to give two figures from the first chapters of the book.

• An estimate of the US losses coming from software failures (both quality or security) at the scale of the whole country: $180 bn a year. (yes billion, not million)
• Deaths occur from software failures. Multiple times per year, if they are not numerous enough to make statistics [yet].

David Rice's point
In the beginning of the book, David Rice argues that software developers have no incentives to make a better work. In chapter 5, Absolute Immunity: You Couldn't Sue Us Even If You Wanted To, David Rice shows that the US government is not making anything against software failures. On the contrary, the US gov gives developers the free hands and no responsibilities of any kind if they should get sued over damages resulting from the use of their software.

And he goes for a short explanation that the US system waits for citizens to become plaintiffs and sue software developers before any public authority will react. He quotes the typical reaction that you would get if you tried to make a law about software quality, through Ronald Reagan's words:
Government is not the solution, government is the problem.

My point
I quite agree with the author on the observation. The US gov does nothing, or goes against any initiative geared towards better software. But I don't agree with the far too simple explanation he gives. I guess a $180 bn issue would get a law if there were no incentives for not making a law. And I can see three reasons a country like the US wouldn't want to improve software quality.

1. "Don't worry, be crappy". This maxim by Guy Kawasaki summarizes well the way software companies get into the subject. They try to output something they can sell, whatever the quality. But this reasoning also goes for countries. Software is a global trade good, and a big software maker as the US doesn't want to slow down the sales by making quality restrictions. If a law were passed, it would probably impact the economy of the country. Same goes for other developed countries.
   In the same train of thoughts, if a law were passed, maybe some development companies would offshore developments.
2. We are still in an early phase of software deployment. Though it is recognized that a big company now has to do better IT rather than more IT, it is still important for many countries, including the US, to do more IT, even at the cost of not doing it better. I mean, a country like the US gets a competitive advantage from doing more IT, getting more automated stuff in its services, agencies, its companies, etc. and would "competitively speaking" lose time by concentrating on the improvement of quality and security.
3. As is long argued in the book, there is an underground market for security vulnerabilities. This market is the fact of underground hackers, but if the underground does it, there are good reasons to believe that the "official" intelligence services do the same. If so, it is rather possible that intelligence services from the typical countries such as the US, France, Israel, Russia or China (which are coincidentally the biggest software developers) have good interest in keeping a high level of not public, unpatched vulnerabilities. They want to know the vulnerabilities themselves, be able to penetrate a lot of places, especially for industrial eavesdropping, and they absolutely do not want software makers to patch the vulnerabilities.

All of these seem better explanations to me for the lack of reaction of developed countries against bad software quality and security.

Articles about Geekonomics to come

Following the return of my copy of Geekonomics: The Real Cost of Insecure Software, by David Rice, I am in the process of writing a few articles about the ideas from the book.

Go read the book if you're interested in understanding the phenomena around and beneath software insecurity and bad quality.

Since I do not want to plunder the author's content by making a detailed summary or quoting the most interesting excerpts, I am selecting a few subjects and trying to explore them a little further than the book. Which will be very hard since I do not have all the investigation sources that Rice may have had, nor patience, skills and experience. For short: I will give some opinions from my understanding of matters in or around the book.

Friday liberty blogging - Assaults on the neutrality of the network

The Internet as we know it: a place almost free of control, with sites rewarded by audience proportional to their qualities, with a good anonymity protecting political dissidents, this place is under high fire from governments and ISPs.
While we might have thought this kind of attacks would come from very liberty killing countries such as China or Iran, they are now in the headlines even in most liberal countries such as France or Germany. To give just a few examples:

• In France, giving as a pretext the fight against illegal downloaders of music and movies, the government is trying to install spywares on all citizens' computers.
• In Germany, giving as a pretext the fight against child pornography, the government gets a law voted for a censorship policy, and stars building an architecture able to filtrate the web's content.
• In England, judges rule that there should be no anonymity for authors of texts made public on the Internet.
• In England, an ISP starts using bandwidth modulation to discriminate against sites helping its competitors' businesses.
  

As far as I know, most of my readers are probably aware of some of these problems. So, instead of commenting on each of these assaults separately, I decided that from now on I would keep a list up-to-date gathering all articles that I would read about this matter. Most should be in English, yet there could be articles in any of the languages I can speak (French, German, Romanian and variants).
The web page of the list is at this address.
You can also find an RSS feed at that address.

Small yet eternal lesson from a successful SQL injection attack

I just conduced a penetration attempt on behalf of a site's owner. The site is the kind you use for home-grown, not critical matters. I wanted to try SQL injections first, because since I read Security Warrior, by Cyrus Peikari and Anton Chuvakin, I felt a kind of inner vacuum for never having done that. Here is how I proceeded:


My goal was to change an existing data of the site to add the mention "hacked". The site was a typical interface to a database, with the notions of "new item", "update item" and "view item" clearly visible.

• From that, I deduced it worked with a database.

Looking at a targetable data, one that I would want to target and mark as "hacked", I saw that the URL contained a GET parameter ?id=20

• From that, I made the assumption that there would be a database table with the field id equal to 20 for the element I wanted to mark as "hacked".

Looking at the main connection page to the site, I saw another GET parameter in which I tried to input a single quote. The server answered me with an error message including the path to a library file, with the extension .php, with an identifiable name. I typed that name into a Google box and found it was a fairly well known free software underlying library.

• From the fact that this library was free software, and that the files were named .php, I made the assumption that the database would be a MySQL one, as is most often the case.

I used the normal way to create an element inside the software of the same kind as that of the element I wanted to change. Then I went to the modification page for this element and gave a single quote in one of the text field values of the element. The server returned me an error message with the faulty SQL request.

• From this I learnt the names of the table and some of its fields inside the database.
• From this, I validated that id was actually a field inside the same table, which I only assumed earlier.
  
• From there, I guessed it would be piece of cake :-)

I crafted a request, using id='20', value of the targeted element instead of that of my legally owned element. I looked on the Internet to find that the comment marker for MySQL was hyphen-hyphen-space and not hyphen-hyphen. And I changed the name field of the attacked element from "dummy title" to "dummy title hacked". And I pressed the button and everything went well. I then used the normal way to visualize data and found the victim element to be called "dummy title hacked".

So, from all that, I conclude that it's important to hide programmer's data from the eye of the user. Especially, GET parameters should not be used unthoughtfully and the error messages from server or middleware should not be displayed to the user. A good polite "We encountered an internal error." is fair enough.

So, next time the webservers' admin or the web dev tells you such small details are not important, just kick him in the balls. I take complaints at cpradier _at_ gmail.com

Larry Page's law also for mobile phones and gaming consoles?

Larry Page once said his thought that "software is going twice slower every 18 months". This became known as Page's law, and I suddenly wondered if the same was not true of mobile phones content and gaming consoles when I had to change my cellphone.

I asked a cousin working in the field of mobile phones and he gave me a spare good old Nokia 1600, saying it's one of the you-cant-find-them-anymore-nor-nothing-as-good.

When I first turned it on, I was overwhelmed by a feeling of quiet efficiency. It's not doing MMS, doesn't take pictures, doesn't allow you to surf the web, but damnit! it's fast. Well, indeed, I just don't notice that I am using a cellphone at all. It's just become plain transparent. Take your directory entry, push the button and that's all. A plain good old feeling of Fire-and-Forget.

And it reminded me how frustrated I got when friends invited me to play the new Street Fighter game on a Xbox 360. It's beautiful, it's respecting the design principles of the series, yet it's no way the same fun as in the old ones on the SNES.

I'd seem bitter if I concluded on a law like "every software or platform evolves to the point where usability suffers a lot from the number of functions, then evolves to the point where it's not usable at all anymore" or another Zawinsky-like law, yet I see no other conclusion.

PS: thx, couz'

ITsec in healthcare - ISO 27799

I recently ordered a copy of the ISO 27799 "Information security management in health using ISO/IEC 27002" because I was curious of the content and I applied to some positions in health organisms. I am fully happy with it and I'll tell you why: it's going further than the ISO 27001 and 27002 norms, but it's also giving examples and diagrams around these norms. So, I think it would be a good read even for someone outside the field of healthcare.

Let me summarize it my own way. The big parts I would make:

1. Introduction on healthcare
2. Lexicon of concepts around ITsec and around healthcare
3. What's specific in the ITsec of healthcare?
4. An action plan for an ISMS "How to be concrete [and successful] in ISO 27001?"
5. A review of ISO 27002 control points and what's specific for them in healthcare.

Once that little summary done, here are my reading notes on what's so specific about healthcare:

• Because hospitals and clinics are open places, because of mobility constraints, and because medical hardware is expensive, there is a high risk in threats related to physical security of the IS.
• There is a very low level of homogeneity both in hardware and in practices for using the hardware.
• There is a devoted and experienced staff, both in IT and in medics, making insider threats lower and making cooperation easier between IT and non-IT people.
• As a good health diagnosis includes various types of data about the patient, the databases about patients are huge and thus, an extremely valuable target.
• Because of the broad interdependency of functions, necessary for the good handling of health issues and making the IS and IT processes extremely complex, it's almost impossible to consider a security initiative on the whole of the IS at once. Or at least it's impossible to have it succeed.
• Thus, definition of good domains of application for a security initiative are needed. Examples are given of adequate sizes for domains of application:
  
• 2 or 3 remote sites
• 50 employees
• 10 processes
• Because of the importance of health itself and that of the public's opinion, cost in money of a project is rarely the first decision factor.

(I can't wait to get started.)