From: Jonathan Leffler (jlefflerus.ibm.com)
Date: Fri Jun 08 2007 - 12:33:21 CDT

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

Valdis.Kletnieksvt.edu wrote on 06/08/2007 10:10:14 AM:
> On Thu, 07 Jun 2007 05:21:06 PDT, Jonathan Leffler said:
> > Wouldn't the person be able to do those things anyway? So, is there
an
> > actual risk of exploitation by someone unauthorized? If the person
> > installing has the privileges to abuse their system and then subverts
an
> > installer into abusing their system, how much of a problem is it
really?
>
> The *real* attack vector here is "Can you, as an outsider, get the
sysadmin
> to run a installer script that *looks* OK at first glance, but ends up
> doing something untoward by abusing the setup.exe that the sysadmin sees
> in the script but doesn't actually look closely at"?
>
> export LICENSE_KEY=`cat license.file`;
> setup.exe
>
> is a good way to get a blob of binary data into the environment without
> too much scrutiny... now if you can get setup.exe to branch to it.. ;)
>
> The *other* corner case to consider - the person has the privs, but is
> untrustworthy, but wants to plant a backdoor for a co-conspirator
without
> the command audit trail showing anything untoward. "Hey, I didn't do
it,
> I just ran setup.exe to install the program. Take a look at the audit
trail,
> that's the only thing I ran..."

Interesting side-light - thanks.

On Windows, I don't think I've ever done things like specially setting the
environment before running an installer - certainly not where I don't
trust the source of the information. Come to that, I don't do it on Unix
either.

The untrustworthy trusted insider is very difficult to deal with -
regardless. It's one reason why I didn't say "some security problems are
too small to be worth fixing". In a world with infinite resources, they'd
all be fixed. However, they do have to be prioritized, and some security
issues are more serious than others (and non-security issues need to be
addressed too - and (too often?) have priority over security). A flaw
that permits unauthenticated remote machine takeover is far more serious
than a flaw that 'only' affects the 'installer only with cooperation from
user'. I'd prioritize the unauth-remote flaw over the installer flaw
every time, for multiple releases if necessary. Ideally, the installer
flaw outlined originally would be fixed too, but I could imagine that lots
of other things get prioritized higher - and resource limitations could
prevent it from being fixed fast.

--
Jonathan Leffler (jlefflerus.ibm.com)
STSM, Informix Database Engineering, IBM Information Management Division
4100 Bohannon Drive, Menlo Park, CA 94025-1013
Tel: +1 650-926-6921 Tie-Line: 630-6921
"I don't suffer from insanity; I enjoy every minute of it!"

• application/x-pkcs7-signature attachment: S/MIME Cryptographic Signature

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]