this scenario is still very unlikely, because the birthday attack method will just produce two randomly garbled files with the same hash.
No-one will accept a patch that introduces some garbled stuff into their repository, as it's just nonsense.
Even if you are able to upload it as a 'firmware patch' which goes by unchecked by everyone else, you still won't be able to produce any form of firmware that'll actually do something you want it to do -- let alone two versions that can run on the same hardware, where one is exploitless and the other has an exploit.
For that kind of stuff you'll have to wait a long time. It's still not even possible with MD5 (though partial data can be preserved with some of the attacks).
I think the idea is that (given the ability to generate SHA-1 collisions) the same technique used to generate MD5 collisions in Postscript files could also be used to generate SHA-1 collisions in firmware files:
http://www.educatedguesswork.org/movabletype/archives/2005/0...
Basically, you generate two colliding blobs of random data, and then append identical code to each of them. The resulting concatenations also collide. The code is designed to behave differently depending on which blob precedes it.
That alone isn't very useful. It would be obvious to anyone who reviewed the code that something is going on, and the whole point of the attack is to fool code reviewers. But if you're clever you could obfuscate this in a number of ways. For example, if you can generate a large number of collisions, you could find a pair of blobs such that a given substring, when interpreted as data or code, produces correct behavior for one version and insecure behavior for the other.
Well, we're talking about programs here. Once you've managed to get an arbitrary, suspicious-but-harmless patch accepted (which, admittedly, is quite the hurdle), you can switch one garbled section for another. Then, you can check which version of the garbled section is in place using your actual code, and branch based on that. There are of course obfuscated variants of this.
This is similar to that exploit on MD5 signatures of PDFs: trick someone into blessing something with harmless effects, and then change part of it so that the effects become harmful. It's not the most dangerous thing in the world, as we have human gatekeepers to ward against this sort of attack, but it may be something to watch out for.
It seems far more likely that the human gatekeepers will be more fallible than SHA1 in this context. How many people really understand the deeper intricacies of C, for example? Submit a patch to a Ruby or Python project to "speed up parsing" that includes a hunk of C. If it actually does speed up parsing, it's possible that the patch would be accepted. Maybe there's also a backdoor in the code. It could take months or years to be discovered, if the project isn't heavily populated by paranoid C programmers and isn't being scrutinized by a lot of people (this is why I generally like really popular Open Source software over niche projects...the level of scrutiny by security experts is much higher).
