Re: Vulnerability Disclosure

[email protected] 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 ([email protected])
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!"