Not a lot you can do?
Anything that requires signatures is vulnerable to forgery if the signer's certificate specifies SHA1.
An attacker could forge:
1. Software signatures - to slip malware into a software vendor's distribution channels.
That requires a second pre-image attack, not just a collision attack. (What gweihir called "two-sided" rather than "one-sided"... though that is not standard terminology).
2. SSL certificates - to MITM web connections to phish, steal data, or distribute malware.
Also requires a second pre-image attack.
3. Personal digital signatures - to fabricate documents, including emails, transaction, orders, etc that are normally trusted implicitly due to the signature
This one can be done with a collision attack. You generate two different documents which hash to the same value, but have different contents. The PDF format, unfortunately, make it pretty easy to generate documents which look sensible and have this property. It's not possible with more transparent formats (not without a second pre-image attack).
4. Subordinate CA certificates - to create trusted certificates which permit all of the above
The problem lies with #4.
This can only be done with a collision attack if the CA is really, really stupid. Proper CAs should include chain-length restrictions in their certificates. That way even if you can create two certificates which hash to the same value, one of which has the keyCertSign bit set to true (which the CA would refuse to sign) and one of which does not (which presumably you can get the CA to sign), it wouldn't matter because if you used the former to generate other certs, no one would accept them due to the fact that your chain is too long.
The only solution is to discontinue the use of SHA1 internally and to revoke trust for all CAs that still use SHA1.
I certainly agree that any CA still issuing certificates with SHA1 should not be trusted. Any existing certs based on SHA1 should be scrutinized, but most of them are still secure.
Better crypto has existed for a long time---the standard for SHA2 was finalized in 2001, well over a decade ago.
Absolutely. Of course, I say that as the maintainer (ish) of an open source crypto library that still uses SHA1. In systems that weren't originally designed for digest agility, it's often hard to retrofit. Today's news is a nice kick in the pants, though.