Re: idea

[Ben <ben () gauntlet ucalgary ca>]

In the extreme case, the machine on which you typed the response cannot 
be completely trusted due to at least the following:
1) Who installed your most recent BIOS update and what's in the microcode?
2) What sneaky/broken stuff was in your most recent OS/application 
install/update?
3) What application modified the last PDF you opened most recently?

As is demonstrated on almost a daily basis, even software and data 
issuing from what we assume to be very strong chains of trust and 
custody can be faulty or compromised without our knowledge for the 
reason that most users do not and cannot personally or through proxy 
verify the providence of every bit of code and data on a particular system.

To use the real-life example, an unpatched Windows XP2 machine installed 
from a original MS CD exposed to the public Internet will get owned in 
several different ways within one hour. If I try to patch the machine 
through Windows Update, I'm assuming that DNS, my ISP, transit 
providers, Microsoft's web host, and Microsoft itself are all not 
compromised and do not want to own my machine. Even if I fully update, I 
know that there are unpatched zero-day things in the wild that can still 
own the box. Even if I do not connect the machine to any network, the 
moment I open any document that the machine itself did not create, I 
expose it to all sorts of macros, scripts and embedded content which can 
hose or exploit my applications. The same weaknesses apply to operating 
systems and applications generally.

Thus, the extreme case is not extreme, but rather normal in that every 
machine is, in a few senses, already well within enemy territory. We 
"hope" that the systems we believe to be secure are actually 
sufficiently secure for the task at hand, and that they are obeying our 
instructions, knowing that they will always be buggy and open to new 
attacks.

The point of worthwhile discussion is the extent to which we can 
mitigate and combat the badness to which the machine must be potentially 
exposed for it to be useful. My preference is to use reasonable means to 
stack the odds as heavily in my favour as possible by addressing as many 
known and plausible threats as feasible, knowing that bad things will 
get through from time to time, rather than to operate in a dysfunctional 
paranoia due to the known threats I can't deal with, or due to the 
unknown threats which must exist but which have not been detected.

Wipe and re-install will not address the classes of technical and social 
vulnerabilities identified in 1), but it would also be costly to exploit 
such flaws and I've seen no evidence that they are a significant, so I 
assume on faith that that chain of trust is unbroken, knowing that 
someone malicious at $manufacturer could some day gain control of my 
machine. I also don't know how to compose e-mail on my abacus, which is 
a system in which I can verify and not just assume almost the entire 
chain of trust (I assume without formal verification that my abacus 
teacher did not embed any exploits in the abacus use knowledge she 
provided me; I cannot safely make similar assumptions about IT use 
knowledge in general).

It is my belief that the present exercise both addresses a known and 
fixable flaw in the chain of trust with respect to the integrity of 
existing virus scanners, and also provides a way to mitigate against a 
particular known and experienced threat. Anyone is free to consider, or 
not consider, the theories and techniques explored through this 
exercise, but consider that if we as the casual good guys can conceive 
of this particular novel technique as both a defensive and offensive 
tool, and demonstrate the defensive component in a day with almost no 
resources (as has been done this week), the well motivated and resourced 
professional bad guys could also conceive of and implement this 
particular novel technique for offensive purposes on a similar timeline 
(except that they would not have to beg cooperation from the AV publishers).

Thank you for the insights,
-Ben


Rich Kulawiec wrote:
> On Sat, Jan 03, 2009 at 04:27:03PM -0700, Ben Li wrote:
>   
> > It would be great to have that as a problem, since that means the AV app 
> > is running on the infected machine. If I can get my resolver on to the 
> > infected machine, I can also get an AV app on to the machine. 
> >     
>
> None of which matters.
>
> A compromised machine is enemy territory.  It no longer belongs to
> its putative owner, and everything it does from that point forward
> is done at the pleasure of its new owners. [1]  Nothing it does
> can be trusted.
>
> So it doesn't matter how clever you (or anyone else) are with AV apps
> and resolvers and DNSSEC and everything else.  You cannot overcome this
> no matter what you do, because you cannot guarantee that the system is
> actually executing the instructions you intend it to execute.  (Note that
> it's quite capable of doing one thing and claiming to do another. [2])
>
> You can *hope* it's executing the instructions you want it to,
> but "hope" is a poor security strategy.
>
> There is only one fix for this: wipe and reinstall.
>
> ---Rsk
>
> [1] I use the plural because systems which are leased out in bulk might
> have a succession of new owners.
>
> [2] I think it's only a matter of time until malware takes advantage
> of virtualization technology to create an instance of the host OS
> and sandbox the former owner into it, while maintaining control
> of the "real" OS.  "But my machine isn't infected" the former owner
> will say, and in a virtual sense, he/she will be correct.  This is
> yet another reason why wipe-and-reboot-from-known-good-media is essential.
> _______________________________________________
> Fun and Misc security discussion for OT posts.
> https://linuxbox.org/cgi-bin/mailman/listinfo/funsec
> Note: funsec is a public and open mailing list.
>   

_______________________________________________
Fun and Misc security discussion for OT posts.
https://linuxbox.org/cgi-bin/mailman/listinfo/funsec
Note: funsec is a public and open mailing list.