Subject: RE: [Nea] RE: Detecting Compromised Endpoints

From: "Thomas Hardjono" <[email-masked]>
Date: Thu, 25 May 2006 21:14:26 -0700

Thanks Frank - yes, you are spot on.
 
My understanding as to how the discussion drifted to trusted hardware
arose from some questions in the IETF.
 
Basically, some folks at the IETF were suggesting that we don't bother
with NEA because (a) any posture agent on the client can be modified by
malware (to then forge posture reports); and (b) They don't believe in
trusted hardware or even the possibility of secure systems.
 
The funny thing is that virtually all protocols invented in the IETF is
subject to changes by malware in (a).  This includes IPsec VPN clients,
routing code, NAT boxes, and even the entire IP stack.
 
Perhaps we should just give-up on the Internet :)
 
cheers,
 
/thomas/

________________________________

From: Frank Yeh Jr [mailto:[email-masked]] 
Sent: Thursday, May 25, 2006 5:57 PM
To: Paul Sangster
Cc: [email-masked]
Subject: RE: [Nea] RE: Detecting Compromised Endpoints

Greetings,

I am a little confused by this thread as it seems to me to be out of
scope with the NEA work. Perhaps I added to the confusion by mentioning
in a previous post that NEA could leverage trusted hardware. For that, I
am sorry (well, sort of).

So my impression of the NEA charter is that the procotol will be about
format, aggregation, and transport of Posture information. There does
not seem to be anything related to establishing trust of the various
components that use the procotol. However, it would be valid to use the
NEA protocols to enable a single collector/validator pair that would
attest to the integrity of all other components. I do not see why this
should be part of the NEA protocols themselves.

This thread probably has to do with the many TCG-aware people
participating in NEA, but I think that is confusing the issue. However,
since I said TCG, I would point out that the TNC specs and the PTS spec
are separate. Why then are we talking about combining these functions in
NEA?

Regards,
Frank Yeh
Corporate Security Strategy Team
IBM
Tivoli Software

"Paul Sangster" <[email-masked]> wrote on 05/25/2006
03:39:02 PM:

> 
> Discussions like these make me wonder what the automotive safety
> engineers must have discussed when the idea of the: seat belt, air
bag,
> crumple zones ... were being considered :).  How many lives do we need
> to save to make it useful ...
> 
> Hopefully we wouldn't pass on doing NEA because its not a panacea for
> security (its not.)  NEA itself doesn't try to solve the problems of
> this thread, we're merely discussing if they might be orthogonal
> mechanisms to help prevent the collector from mis-reporting the
> situation.   Putting a spotlight on the desire to report configuration
> should help bring focus to protecting the collection/reporting
> mechanisms.
> 
> So with that said, let go into the interesting dialog.  Clearly you've
> raised very interesting and challenging issues that most (all?) of our
> other standards couldn't live up to (fortunately, there are threat
> models to save the day by scoping them out :))
> 
> > -----Original Message-----
> > From: Marcus Leech [mailto:[email-masked]] 
> > Sent: Thursday, May 25, 2006 11:20 AM
> > To: Stephen Hanna; [email-masked]
> > Subject: RE: [Nea] RE: Detecting Compromised Endpoints
> > 
> > 
> > 
> > 1) What needs to be measured?
> > 
> >    All the trusted code on the endpoint needs to be measured.
> >    That includes all the software and firmware in the Trusted
> >    Computing Base, any code whose compromise would potentially
> >    cause the system to violate its security policies. This
> >    includes the BIOS, the boot loader, the OS kernel, the
> >    kernel drivers, etc. If the operating system is well written,
> >    it should not include application code since that code
> >    cannot cause the system to violate its security policies.
> > 
> > The essential problem is that for any *practical* operating system
for
> >   purposes of general-purpose computing, there *is* application
code,
> >   the compromise of which, can cause the system to violate 
> > its security
> >   policies.
> 
> Sure, privileged code also runs in applications so the kernel doesn't
> need to contain everything.  Ideally OSes would limit privileges
> (ability to bypass some security check) more granularly (e.g. Solaris
> 10's privilege model) but many do not or the granularity isn't used so
> point taken.
> 
> I think one of the areas of discussion around the use of TCG
> verification is how to enable product vendors (or 3rd party
"integrity"
> oriented vendors) to define trust dependency trees so that verifiers
can
> determine what set of component measurements it needs to verify to
feel
> safe trusting the requesting system for a particular purpose.  For
many
> use cases, only portions of the machine need to be checked (e.g when
> your just trusting a browser session so need to check the kernel,
> privileged apps and things relied upon by the brower.
> 
> I don't think this is an unsolvable problem, just a hard one.  We need
> an ongoing dialog to understand what is running on the requesting
system
> that needs to be trusted and traverse its trust dependency tree.  For
> NEA this might be the kernel plus the set of privileged apps and some
> security configuration information or it might involve checking a
> special security partition + hypervisor (depending on the system
> architecture.)
> 
> > 
> > The only thing the hash does is to assert that the code is 
> > free from any
> >   *known* vulnerabilities.  Once the system is compromised, 
> > it can continue
> >   to provide an idyllic view to the TPM/PCR machinery.
> 
> The hash just records that a particular image of code was run on the
> system (so it could later or immediately be verified [*]) in a way
that
> can't be hidden.  The TPM only allows "extends" to the PCR so trusted
> apps can effectively add to the values but not remove prior entries.
> The meta-data about each extend is stored in a measurement log and is
> used for verification.  A rootkit might be able to alter the
measurement
> log but to hide its existance but it wouldn't be able to change the
PCRs
> to erase its measurement.
> 
> The way the TPM is used it has the capability of signing the PCRs with
a
> private key for a particular attestation to a verifier.  The verifier
> needs an equivalent measurement log (history of the PCR) to verify
that
> it correctly recomputes the aggregate current value stored in the
PCR(s)
> and can verify the meta-data makes sense and is considered valid by
> policy.  I'm not sure how malware that was measured into a PCR could
> hide its presence without resetting the PCR back to a desired value.
> 
> [*] - Background: the model allows for a local verifier that checks
code
> measurements against a set of known valid measurements before allowing
> it to run. This effective prevents code with known vulnerabilities
from
> running and establishes a trustworthy base to build upon as long as
you
> can trust the verifier (done via chain of trust.)  As Marcus correctly
> points out this doesn't catch unknown vulnerabilities.  The TCG
> technology that I know of doesn't do behavioral checking although such
> technologies do exist and watch for zero-day attacks as we speak.  You
> could imagine that these could be integrated and will evolve over
time.
> 
> > 
> > 
> > 3) How does the Posture Validator get that list of PCR values
> >    for known good configurations?
> > 
> >    Typically from a subscription service that maintains a
> >    list of PCR values for various versions of software from
> >    all the major vendors. The decision about which software
> >    versions are "good" is a policy decision generally left
> >    to the network owner.
> > 
> > You have to assume that a compromised system would be able to
maintain
> >   a consistently-idyllic view using some similar type of 
> > "subscription service".
> >   Essentially, a compromised system can continue to update 
> > the view of the
> >   world it wishes to present to the TCG subsystems.  The 
> > *reality*, however,
> >   will be quite different.
> 
> Same comment as above.  How does the malware reset the PCRs back to
the
> idyllic values so future attestations comes up clean?  Most of the
PCRs
> do not allow "set" type of operations, so this means the malware
> couldn't use the TPM signed set of PCR values to spoof the verifier
(nor
> could it use the TPM's cert since it lacks access to the private key
to
> quote (sign) the incorrect pseudo-PCRs.)
> 
> >  
> > 
> > 4) Won't this prevent me from using my favorite OS?
> > 
> >    That depends on your network's policy. If you don't like
> >    their policy, you're free to shop around. Remember that
> >    the TPM is an optional component and comes disabled. You
> >    can just leave it disabled. Or you can run your favorite
> >    OS within an untrusted application. Or you can have an
> >    untrusted application forward packets from your favorite OS.
> >    Anyway, those subscription services aren't cheap. Trusted
> >    boot will probably be mainly deployed in high-security
> >    environments.
> > 
> > There's also the scenario of a NAT-like device in a 
> > TCG/TPM/NAP/NAC/whatever
> >   world.  You have a "policy-compliant" system act as a proxy 
> > for a pool
> >   of non-compliant nodes.  "Fixing" that kind of scenario 
> > tends to produce
> >   a system that is unusable for ordinary use.  Perfectly 
> > secure, and utterly
> >   unusable.
> 
> Not sure I follow.  Are you referring to the tunneling attack
discussed
> in the TNC's IF-T specification or a true proxy?  In the true proxy
> case, the proxies should show up in the list of measurements required
by
> the verifier and the verifier's policy DB shouldn't allow this
> configuration.  For the nested tunnel attack, there are already
> suggested countermeasures and work is underway for more (not
> unsolvable.)
> 
> Was your comment about "fixing" the proxy case meaning that systems
need
> to be able to run such software or else they aren't useful?  Maybe you
> could explain more about your thinking?
> 
> > 
> > 5) How does this let the server detect endpoint compromise?
> > 
> >    If a trusted software component on the endpoint has been
> >    compromised, that will show up as a PCR with an unrecognized
> >    value. Because the TPM hashes the software before it's run
> >    and won't let the software zero the PCR (and because the
> >    hash is preimage resistant), the compromised software can't
> >    get the TPM to report a valid PCR value. And it can't
> >    replay an old PCR value because of the nonce.
> > 
> > That only applies to "compromised on disk".  The state of 
> > said software
> >   at some time T after it has begun executing *cannot* be
attested-to
> >   by anything.  If that were possible, then it would imply having a
> >   general solution to the halting problem.  In fact, even the 
> > known-good
> >   PCR values are only attesting to the fact that the software 
> > is known to
> >   be resistant to all the vulnerabilities we *know about* in 
> > the software.
> >   With the emergence of zero-day exploits of vulnerabilities, I
wonder
> >   how useful this will actually be.
> 
> Without trying to solve the halting problem you can introduce
mechanisms
> to help raise the security level of the system.  Is this useless to
try
> unless they are foolproof?  There are an endless list of security
> mechanisms which can't address this issue (bug in an IKE
implementation
> leaks phase 2 keys, buffer overflow of a privileged daemon and now we
> can change TLS trust anchors, timing attack against processor caches
and
> you can learn OpenSSL private keys ...)  I agree it's a hard problem
but
> hope we don't let it stop progress.  People are working (and shipping)
> technologies to try to catch zero-day exploits and these could be
> integrated with other system integrity protection features to raise
the
> bar as best we can without waking Mr Turing :).
> 
> If a system measured all software as its loaded and check it was clean
> against known vulnerabilities, recorded the measurement in a TPM (or
> tamperproof environment) and created a measurement log, used AV and
> behavioral techniques to watch for viruses in running code, ... and
was
> able to produce an attestation of all of this and the
> configurations/databases it used in a non-spoofable way, this seems to
> be better then we have today.  Add in support for separate protection
> domains to isolate security mechanisms (and logs) and we seem to be
> raising the bar.
> 
> Of course this isn't TNC, but its something orthogonal that people in
> the industry are working on and seems to fit in with what is being
> planned.  Such integrity mechanisms could offer a Posture
> Collector/Verifier pair to fit into the NEA model.
> 
> >    
> > 6) Aren't there ways to attack this system?
> > 
> >    Yes. You can break the system if you can successfully attack
> >    any one of these: the TPM (with physical attacks or by finding
> >    flaws in it), the CAs that signed the TPM's certificates (or
> >    their operators), the trusted software that's listed in the
> >    known good configs, the cryptographic algorithms and protocols
> >    involved, or the Network Enforcer or the NEA server or their
> >    operators. There's also a clever attack described in Appendix A
> >    of the TNC IF-T document. Countermeasures for that attack are
> >    given in that document.
> > 
> >    I have omitted some attacks for which countermeasures are
> >    available. If you have other attacks you're interested in,
> >    please raise them and I'd be glad to address them.
> > 
> > 7) Won't there inevitably be vulnerabilities in the trusted
software?
> > 
> >    Yes. That's true today. It will probably always be true. 
> > The best way
> >    to handle it is to reduce the number of vulnerabilities by making
> >    the trusted software as small and secure as possible. Beyond
that,
> >    identify vulnerabilities as soon as possible (preferably before
> >    exploits are available), prepare fixes, and then remove 
> > the old buggy
> >    software from the list of known good configurations (or 
> > move it to a
> >    list of configurations that require quarantine and mandatory
> >    remediation).
> > 
> > The problem is that *real* generally-useful computing 
> > environments are still
> >   going to have very large components that have to be trusted 
> > to behave
> >   correctly at all times.   If you have an operating system 
> > that has all
> > those
> >   desirable properties, then you don't need any of this 
> > TPM/TNC/NEA/TCG goop.
> 
> Ah, but this means that we do need TPM/TNC/NEA/TCG goop :).  Clearly
> big, complex software will have security bugs that will get fixed and
> patches released.  Hopefully NEA will help get the lack of those
patches
> recognized and distributed more quickly (being more centrally
> controlled) but will need new measurement policies provisioned
quickly. 
> 
> > 
> > The raison d'etre for this stuff is precisely because 
> > operating systems today
> >   are vulnerable due to a large number of factors, including 
> > broken architectures,
> >   programming language design, human frailty, etc, etc.  And 
> > it is precisely because
> >   of that that this stuff can't be made to work, for any 
> > sufficiently-rigorous
> >   definition of the word "work".
> > 
> > The bad guys are getting cleverer, and a large fraction of 
> > the "good guys" haven't
> >   actually done any detailed analysis of all this 
> > TCG/TNC/TPM/NEA stuff yet.
> 
> Having an NEA WG just helps bring exposure to this area so more
detailed
> analysis can be performed and we can improve the situation.  The
> TCG/TNC/TPM specs are public so can be reviewed.  Their have been a
> number of good cryptographers and security people who have reviewed
the
> TCG stuff but it's a work in progress so hopefully this momentum will
> continue.
> 
> >   I fully expect that there will be gaping holes found within 
> > two years.
> 
> That's why we have version 2 :).  History is certainly on your side
> (SSHv1, SSLv1, Kerberos v4, ...) have all needed updates to improve
> based on holes, I'm sure this will be the same.
> 
> > 
> > I'd be perfectly delighted to be proven wrong.
> 
> Sorry but you'll still have a job for a few more years :).
> 
> > 
> > 
> > _______________________________________________
> > Nea mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/nea
> > 
> 
> _______________________________________________
> Nea mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/nea

_______________________________________________
Nea mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nea

---

From: "Marcus Leech" <[email-masked]>
Date: Fri, 26 May 2006 07:52:23 -0400

Thomas Hardjono wrote:
> with NEA because (a) any posture agent on the client can be modified 
> by malware (to then forge posture reports); and (b) They don't believe 
> in trusted hardware or even the possibility of secure systems.
>  
> The funny thing is that virtually all protocols invented in the IETF 
> is subject to changes by malware in (a).  This includes IPsec VPN 
> clients, routing code, NAT boxes, and even the entire IP stack.
>
I was going to simply let my contributions to this thread die, having 
said what I wanted to say.

But this just has to be answered.  There's a fundamental difference 
between compromise of something like an IPSEC
  client, and compromise of an agent.  If I compromise an IPSec client 
in some way, it doesn't affect the security
  state of the VPN gateway, only that of the client.

In the TCG scenario, security decisions made by the network as a whole 
rely entirely on the agent behaving
  correctly, including not having been compromised.  You're making 
security decisions based on information
  that can't be independently verified.  When I assert that I'm 
[email-masked] to some gateway or NAS
  or whatever, my credentials (password, certificates, etc) act as a 
method of "indepenent verification" of my
  [email-masked] assertion.    Just because a remote, 
turing-complete, machine *asserts* that it is sane, and
  has notarization to "prove" it, doesn't necessarily make it so, and 
there's no way for the network infrastructure
  to verify those assertions with the same kind of solidity as verifying 
my [email-masked] assertion by way
  of credentials.  No amount of cryptographic mumbo-jumbo can get around 
that very fundamental problem,
  IMHO.

Anyway, I'm done.  Everyone knows what my opinion is on the fundamentals 
here, but to the extent that we
  all have drunk the kool-aid at some level, there needs to be protocol 
standards, and *that's* what NEA
  is all about.

> Perhaps we should just give-up on the Internet :)
Well, that's a whole other topic :-)

---

From: "Stephen Hanna" <[email-masked]>
Date: Fri, 26 May 2006 16:26:39 -0400

One of the most common objections to NEA (and similar
systems) is "If the endpoint is compromised, you can't
trust anything it says." This issue continues to come
up again and again. Several people on the NEA list have
asked to have the charter address it, saying that it is
out of scope for NEA (except that it will be addressed
in the overall security analysis).

The reason I started a separate thread on the topic
of Detecting Compromised Endpoints was so that we could
have a reasoned discussion of the problem and then
refer future people who raise the issue to this thread.
I said this in the first email on this thread. Thanks
to all who have contributed to the thread. I think it
has largely run its course.

I will now draft some language on this for the charter
and submit this for the mailing list to consider. I'll
use a separate thread so we can keep this thread just
for discussion of the technical problem of how and
whether compromised endpoints can be handled.

Thanks,

Steve 

> From: Thomas Hardjono [mailto:[email-masked]] 
> Sent: Friday, May 26, 2006 12:14 AM
> To: [email-masked]; Frank Yeh Jr
> My understanding as to how the discussion drifted to trusted 
> hardware arose from some questions in the IETF.
>  
> Basically, some folks at the IETF were suggesting that we 
> don't bother with NEA because (a) any posture agent on the 
> client can be modified by malware (to then forge posture 
> reports); and (b) They don't believe in trusted hardware or 
> even the possibility of secure systems.
>  
> The funny thing is that virtually all protocols invented in 
> the IETF is subject to changes by malware in (a).  This 
> includes IPsec VPN clients, routing code, NAT boxes, and even 
> the entire IP stack.
>  
> I am a little confused by this thread as it seems to me to be 
> out of scope with the NEA work. Perhaps I added to the 
> confusion by mentioning in a previous post that NEA could 
> leverage trusted hardware. For that, I am sorry (well, sort of).
> 
> So my impression of the NEA charter is that the procotol will 
> be about format, aggregation, and transport of Posture 
> information. There does not seem to be anything related to 
> establishing trust of the various components that use the 
> procotol. However, it would be valid to use the NEA protocols 
> to enable a single collector/validator pair that would attest 
> to the integrity of all other components. I do not see why 
> this should be part of the NEA protocols themselves.
> 
> participating in NEA, but I think that is confusing the 
> issue. However, since I said TCG, I would point out that the 
> TNC specs and the PTS spec are separate. Why then are we 
> talking about combining these functions in NEA?
> 
> Regards,
> Frank Yeh
> "Paul Sangster" <[email-masked]> wrote on 
> 05/25/2006 03:39:02 PM:
> 
> > 
> > engineers must have discussed when the idea of the: seat 
> belt, air bag,
> > > The essential problem is that for any *practical* 
> operating system for
> > >   purposes of general-purpose computing, there *is* 
> application code,
> > oriented vendors) to define trust dependency trees so that 
> verifiers can
> > determine what set of component measurements it needs to 
> verify to feel
> > safe trusting the requesting system for a particular 
> purpose.  For many
> > an ongoing dialog to understand what is running on the 
> requesting system
> > system (so it could later or immediately be verified [*]) 
> in a way that
> > used for verification.  A rootkit might be able to alter 
> the measurement
> > log but to hide its existance but it wouldn't be able to 
> change the PCRs
> > The way the TPM is used it has the capability of signing 
> the PCRs with a
> > needs an equivalent measurement log (history of the PCR) to 
> verify that
> > it correctly recomputes the aggregate current value stored 
> in the PCR(s)
> > [*] - Background: the model allows for a local verifier 
> that checks code
> > it to run. This effective prevents code with known 
> vulnerabilities from
> > running and establishes a trustworthy base to build upon as 
> long as you
> > could imagine that these could be integrated and will 
> evolve over time.
> > 
> > > 
> > > 
> > > You have to assume that a compromised system would be 
> able to maintain
> > Same comment as above.  How does the malware reset the PCRs 
> back to the
> > idyllic values so future attestations comes up clean?  Most 
> of the PCRs
> > couldn't use the TPM signed set of PCR values to spoof the 
> verifier (nor
> > could it use the TPM's cert since it lacks access to the 
> private key to
> > Not sure I follow.  Are you referring to the tunneling 
> attack discussed
> > case, the proxies should show up in the list of 
> measurements required by
> > Was your comment about "fixing" the proxy case meaning that 
> systems need
> > >   With the emergence of zero-day exploits of 
> vulnerabilities, I wonder
> > Without trying to solve the halting problem you can 
> introduce mechanisms
> > to help raise the security level of the system.  Is this 
> useless to try
> > can change TLS trust anchors, timing attack against 
> processor caches and
> > you can learn OpenSSL private keys ...)  I agree it's a 
> hard problem but
> > integrated with other system integrity protection features 
> to raise the
> > behavioral techniques to watch for viruses in running code, 
> ... and was
> > > 7) Won't there inevitably be vulnerabilities in the 
> trusted software?
> > > 
> > >    the trusted software as small and secure as possible. 
> Beyond that,
> > patches released.  Hopefully NEA will help get the lack of 
> those patches
> > controlled) but will need new measurement policies 
> provisioned quickly. 
> > 
> > > 
> > Having an NEA WG just helps bring exposure to this area so 
> more detailed
> > number of good cryptographers and security people who have 
> reviewed the