7

Some time after I asked What happens to you if you break the monad laws? I stumbled across this unexplained phrase on Haskell Wiki, on a page about Safely running untrusted haskell code:

"creating class instances that violate assumed laws (cf EvilIx)"

as an example of an exploit that was possible against lambdabot.

Since lambdabot uses GHC presumably this was a bug (or feature) of GHC making assumptions about class laws. Does anyone remember what those are? And has this ever (or could it possibly) happen acidentally?

(googling for "haskell +Evillx" turns up no hits).

Community
  • 1
  • 1
Owen
  • 38,836
  • 14
  • 95
  • 125
  • 7
    Breaking the Typeable representation is a fairly compelling example. `instance Typeable Int where typeRep = "Bool"` – Don Stewart Aug 07 '11 at 03:43
  • 2
    EvilIx: http://www.haskell.org/pipermail/haskell-cafe/2006-December/019994.html – sclv Aug 07 '11 at 05:50
  • Isn't Typeable the only class that can actually cause trouble? – augustss Aug 07 '11 at 09:24
  • @sclv: thank you for the EvilIx reference: I had had it spelled wrong! (darn font making l and I look the same). I like that example because it's terrible "normal" -- it's the exact same kind of security problem you'd get in C by not checking your indices. – Owen Aug 10 '11 at 09:43
  • @sclv,DonStewart you could post those as an answer... – Owen Feb 04 '12 at 03:16

2 Answers2

4

If we think of a monad as modelling side effects, a type claiming to be a monad but not obeying the laws can result in effects occurring in the wrong order or the wrong number of times.

A classic example of this is ListT, the list monad transformer. The original implementation didn't satisy the monad laws. The "ListT Done Right wiki page has some simple examples of usage of ListT in the section called "Examples". You can see the difference between what these programs do when you run them with the original implementation that violates the laws, and when you run them with a replacement that satisfies the laws.

Yitz
  • 5,057
  • 24
  • 19
4

Arrays use Ix to manage bounds. They trust that Ix does what it says. If it doesn't, you can trick the array mechanisms into accessing memory locations that aren't theirs.

cf EvilIx: http://www.haskell.org/pipermail/haskell-cafe/2006-December/019994.html

sclv
  • 38,665
  • 7
  • 99
  • 204
  • This exploit does not work in GHC 7.6 anymore, I believe it was fixed but can't find a source. – sdcvvc Feb 11 '13 at 09:56