Opened 15 months ago

Last modified 12 months ago

#7634 new bug

MD5 collision could lead to SafeHaskell violation

Reported by: shachaf Owned by:
Priority: normal Milestone: 7.8.3
Component: libraries/base Version: 7.6.1
Keywords: Cc:
Operating System: Unknown/Multiple Architecture: Unknown/Multiple
Type of failure: Other Difficulty: Unknown
Test Case: Blocked By:
Blocking: Related Tickets:

Description

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.

Change History (1)

comment:1 Changed 12 months ago by igloo

  • Difficulty set to Unknown
  • Milestone set to 7.8.1
Note: See TracTickets for help on using tickets.