Re: FreeBSD Security Advisory FreeBSD-SA-05:09.htt [REVISED]

From: Poul-Henning Kamp (phk_at_phk.freebsd.dk)
Date: 05/14/05

  • Next message: Drew B. [Security Expertise/Freelance Security research].: "Re: FreeBSD Security Advisory FreeBSD-SA-05:09.htt [REVISED]" 
    To: "Drew B. [Security Expertise/Freelance Security research]." <d4rkstorm@gmail.com>
Date: Sat, 14 May 2005 04:20:19 +0200

    In message <245f0df105051318564b1ffb6b@mail.gmail.com>, "Drew B. [Security Expe
    rtise/Freelance Security research]." writes:

    >this sounds like trying to solve in the OS a problem that can only
    >be solved in the application. Is there something more subtle
    >that's going on?

    Well, the application could theoretically do something and Colin
    advocated it this morning: make the crypto code footprint data
    and key independent. While possible, it is both very tricky to
    do (in particular in highlevel languages) and generally found
    to be much slower than speed-optimized code.

    And while that could solve the immediate panic with OpenSSL and
    similar, it does not solve the general problem that you can spy
    very efficiently on the behaviour of another program.

    The fact that one user would be able to spy on another users editor
    application and be able to extract for instance the word lengths
    and layout of a document would also be considered a major security
    problem in many installations.

    Or how about just being able to monitor another customers apache
    instance to figure out how much traffic they get and which pages
    they get it on ?

    The fundamental trouble is that HTT makes the spying far more
    efficient than it is with SMP or even UP (I think we are talking
    in the order of a million times more efficient).

    That takes the attack from the "if you were really lucky" to the
    "almost always in first try" category.

    The correct (technical) workaround (IMO) is to restrict HTT to be
    used only for threads from the same process.

    The political problem is that if all operating systems do that,
    Intel has a pretty dud feature on their hands, and they are not
    particularly eager to accept that fact.

    Poul-Henning 

    -- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk@FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.
_______________________________________________
freebsd-security@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "freebsd-security-unsubscribe@freebsd.org"
  • Next message: Drew B. [Security Expertise/Freelance Security research].: "Re: FreeBSD Security Advisory FreeBSD-SA-05:09.htt [REVISED]"