On Sat, Mar 17, 2007 at 11:08:12AM +0000, Ian Collier wrote: > > Say there's a (purely hypothetical) bug in Mutt which allows an > > attacker to cause mutt to download an arbitrary file (perhaps actually > > in an application frequently used to aid mutt in viewing mail and/or > > attachments, e.g. lynx). Say the bug allows the creation of the file, > > but in no way allows for the execution of code within the file. Such > > bugs have existed. > > In that case, you get them to download an authorized_keys file for ssh... Well sure, there's only so much Mutt can do on its own -- and remember, we're talking about mitigating a (hypothetical) bug in Mutt.. it's already not a perfect situation. But the attack you mention can be foiled in a number of ways. First off, the user can (and should) have his system firewalled off so that only trusted hosts can ssh to his system. This can be accomplished by either setting up firewall software on your machine (least effective), or putting your home machine behind a broadband router of some kind, or by installing a dedicated firewall (at work, or if you have the resources) to protect your LAN (most effective). In the case of local firewall software, the user would need to add rules to allow SSH access only from (relatively) trusted hosts. Secondly, the authorized_keys file should be at most -r--r--r--. In most cases, that will prevent the kind of bug I'm talking about from allowing the file to be exploited: the user himself has no write access to the file, so opening it for writing will fail. It's also possible to have a multi-factor authentication scheme: i.e. the system could require BOTH ssh rsa authentication, AND that the user enter his valid password. This is a good idea especially for, say, your firewall, or any directly Internet-connected machine. Unfortunately, we're talking mostly about users who have a limited security clue, so they're not likely to do any of these things. As I said, there's only so much you can do, but that's not a reason NOT to do what you can. Let's say the bug is in lynx, which the user uses to view HTML mail. He reads the mail, and it contains a trojaned payload which triggers lynx to download some malicious file to the user's system. Is that malicious file likely to replace the .muttrc? The odds are exceedingly low: the exploit targeted lynx -- the attacker has no idea if mutt is even installed on the system. If the exploit were against Mutt itself, then most likely the attacker is going to try to leverage that attack through something that mutt does, and is known to do. He has no way to be sure that the user uses SSH, and indeed the system he's using it on may not use RSA authentication at all. When you're trying to write an exploit for a particular bug, the most successful exploit will be one that makes use of things you know will be present on the system. Thus if you're exploiting a bug in mutt, you want to trojan something that mutt does, like modify its config file to execute arbitrary code of your choice. I mentioned a way to make that attack fail in a different subthread. If you can't manage to do that, then your next best bet is to trojan some other program that is very commonly used. A great example I already mentioned is to insert a trojaned ls binary in the user's path. The attacker needs to guess where the path is, and there's a pretty good chance the attack will fail, but odds are better than trying to replace the authorized_keys file and ssh in. Though, if the bug you're exploiting allows you more freedom than simply uploading a file, then you'll be able to try multiple methods, and anything you can think of is worth trying -- up to a point... If it takes too long, the user might notice that something is amis, and then start poking around to see what's going on. -- Derek D. Martin http://www.pizzashack.org/ GPG Key ID: 0xDFBEAD02 -=-=-=-=- This message is posted from an invalid address. Replying to it will result in undeliverable mail. Sorry for the inconvenience. Thank the spammers.
Attachment:
pgpMUMO8fVwP2.pgp
Description: PGP signature