MD5 collision could lead to SafeHaskell violation
The current scheme for computing TypeRep fingerprints is: md5sum (encodeUTF32BE (unwords [moduleName, packageName, typeName])). SafeHaskell doesn't allow custom-written Typeable instances, but this is more or less the code that deriving Typeable generates.
MD5 is broken and not collision-resistant. If someone can make an MD5 collision, they could use it to derive unsafeCoerce and execute arbitrary code. The constraints (UTF-32, names being alphanumeric, etc.) make it pretty tricky to find a valid collision by the standard methods, but I don't know enough about this to say how feasible it is.
It seems to me that, especially with new-typeable, it might not be necessary to use hashing at all, if GHC can figure out fingerprints statically. Or maybe separate compilation requirements make that unworkable (in which case maybe using a hash of the package/module name along with a separate per-module counter, or something along those lines, might be better, since people are less likely to control those? I'm not sure). Maybe the solution is just switching to another hash function, or something else. At any rate, the issue should be considered -- using MD5 isn't a good idea in cases where collisions could have security implications.
Trac metadata
| Trac field | Value |
|---|---|
| Version | 7.6.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | libraries/base |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture |