<<< Date Index >>>     <<< Thread Index >>>

Re: [PATCH] Remove absolute paths from gpg.rc



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