lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Fri May 5 02:13:56 2006 From: bill.stout at greenborder.com (Bill Stout) Subject: How many vendors knowingly ship GA product with security vulnerabilities? Thanks Vladis, That's an excellent and well thought out reply. Sounds like you have some experience in delivering software. It would seem that if a few days buffer were built into the system, specifically to check in security fixes prior to QA; that would be a huge 'CYA' benefit to prevent those 'CLM' moves and to protect the consumers of the software. Bill Stout -----Original Message----- From: Valdis.Kletnieks@...edu [mailto:Valdis.Kletnieks@...edu] Sent: Wednesday, May 03, 2006 11:10 PM To: Bill Stout Cc: full-disclosure@...ts.grok.org.uk Subject: Re: [Full-disclosure] How many vendors knowingly ship GA product with security vulnerabilities? On Wed, 03 May 2006 22:23:42 PDT, Bill Stout said: > If a patch is ready in just a few days, and QA for a patch takes several > weeks, it would seem the vendor already knew about the vulnerability and > had a fix ready, either for next release or vulnerability discovery, It would *seem* that way, yes. But it often doesn't work that way. Quite often, the bug is a Homer Simpson "D'Oh!" error (such as most buffer overruns), so a "first cut" of a patch can be done in a few *hours*. > which ever came first. Otherwise the fix would take weeks to test and > release in order to test all compatibilities related to the bug fix, > correct? But it can *still* take a while to actually integrate and test the fix, especially if it involves an API change. For instance, a buffer overflow may be fixed by passing in a new "length" parameter. Then you have to find and fix all the places that call the function, to also pass the length, and then find all the places that call those places, and so far... And if you're *really* unlucky, the API change goes to multiple code repositories for multiple products... and things get *really* ugly. Try it sometime - pull down the source for Firefox or OpenOffice, which are "average" sized for large software systems. Unpack it someplace (make sure you have multiple gigabytes of disk available). Now find some random foo.h file somewhere in the tree. Find a 'struct' in that .h, and add one more thing to that struct. 'int blat;' is good enough. Now see how long it takes you to find every use of that struct, and add a 'foo_struct.blat = 5;' (or 6, or 9, or different value at each use). Then have fun tracking down all the *implicit* uses - code that uses sizeof(), or places where the code blows up if 'sizeof(struct foo_struct)' is over the size you can store in a certain field in a database. Oh, and don't forget to find that XML file that generates the marshal/demarshal code for this.... ;) > So, my question is, if the vendor knew about vulnerabilities before a > product was released, why wouldn't they simply delay the ship a few days > in order to QA the patch for vulnerabilities they already knew about? There's this thing called a 'freeze date', and it's often several *months* before the planned 'ship date'. You have to freeze the code at *some* point, do the QA, and at some point produce a .ISO or similar to send to burn CDs. Then you have to send the CD off to be duplicated (even a *big* duplicating shop is going to take a while to produce 10,000,000 burned, custom artwork, manuals, into a box and shrink wrapped and sent to Office Max and Best Buy and Walmart and everyplace else. Oh, and you need to send copies to whatever PC manufacturers bundle it, so Dell and HP and Levono can integrate it into the images *they* install. So you're sitting there, 3 million CD's burned, Dell and HP ramping up and Levono ready to go tomorrow - and you want to *delay a few days* because there might be a bug???? Somebody's gonna *pay* for that fuck-up. It's a CLM (Career-Limiting Move). http://today.reuters.com/business/newsArticle.aspx?type=technology&story ID=nN02271704 Vista is slipping *again*. And the news took MSFT stock down 0.22 to $24.07. That's a 1% hit in market value. And that means that Gates's $40B in MSFT stock just dropped $400M in value. That means Gates is gonna rip Ballmer a new one (wouldn't *you* if you just lost $400M?). Ballmer is gonna rip somebody a new one, and so on down the line. You wanna be the software engineer at the end of that line? You're gonna get ripped so many new ones, you're gonna be called "Swiss Cheese" at your next job... And it's not limited to proprietary software either - the guys over at Firefox just released 1.5.0.3 to fix a nasty flaw. Now, *somebody* had to make the hard call "We ship 1.5.0.3 *now* to fix this bug, and the stuff that *was* targeted for 0.3 is going to slip to 0.4". Do you want to be the software engineer that tries to say "Umm.. can we hold 0.3 for a week and a half while we get these 3 minor bugfixes finished?"
Powered by blists - more mailing lists