Friday, March 20, 2009

The Sky Is Falling?

A few reporters asked me if our recent paper on SMM attacking via CPU cache poisoning means the sky is really falling now?

Interestingly, not many people seem to have noticed that this is the 3rd attack against SMM our team has found in the last 10 months. OMG :o

But anyway, does the fact we can easily compromise the SMM today, and write SMM-based malware, does that mean the sky is falling for the average computer user?

No! The sky has actually fallen many years ago… Default users with admin privileges, monolithic kernels everywhere, most software unsigned and downloadable over plaintext HTTP — these are the main reasons we cannot trust our systems today. And those pathetic attempts to fix it, e.g. via restricting admin users on Vista, but still requiring full admin rights to install any piece of stupid software. Or selling people illusion of security via A/V programs, that cannot even protect themselves properly…

It's also funny how so many people focus on solving the security problems by "Security by Correctness" or "Security by Obscurity" approaches — patches, patches, NX and ASLR — all good, but it is not gonna work as an ultimate protection (if it could, it would worked out already).

On the other hand, there are some emerging technologies out there that could allow us to implement effective "Security by Isolation" approach. Such technologies as VT-x/AMD-V, VT-d/IOMMU or Intel TXT and TPM.

So we, at ITL, focus on analyzing those new technologies, even though almost nobody uses them today. Because those technologies could actually make the difference. Unlike A/V programs or Patch Tuesdays, those technologies can change the level of sophistication required for the attacker dramatically.

The attacks we focus on are important for those new technologies — e.g. today Intel TXT is pretty much useless without protection from SMM attacks. And currently there is no such protection, which sucks. SMM rootkits sound sexy, but, frankly, the bad guys are doing just fine using traditional kernel mode malware (due to the fact that A/V is not effective). Of course, SMM rootkits are just yet another annoyance for the traditional A/V programs, which is good, but they might not be the most important consequence of SMM attacks.

So, should the average Joe Dow care about our SMM attacks? Absolutely not!

10 comments:

  1. Great sense of humor, and spot on. Thanks for your work.

    ReplyDelete
  2. Will or will not the injected code go away after a reboot?

    Thank you.

    ReplyDelete
  3. @anon_asking_about_persistence_in_the_wrong_place:
    Of course it will go away, it's not persistent.

    ReplyDelete
  4. Thanks ur job. great job

    ReplyDelete
  5. Perfectly, I share your opinion.
    U like a Richard Stallman :)

    ReplyDelete
  6. I join the other people and say thank you and all the other people working on that. It's one of my many sources of continous learning.
    What amazes me the most is that nobody outside "the matrix" takes the lead and tries to get all the people out ...
    Probably is just not meant to be, and we need to face the destruction of Zion to realize what path to take in the future to avoid coming back to the "paper and pencil" state.

    ReplyDelete
  7. The article makes for an interesting read. Now there's something that got me thinking and it's driving me crazy.

    The BIOS should lock the SMRAM region right after loading the code to it. And this is most likely happening, right?

    Changing MTRR to set the SMRAM region to cacheable write-back should not have an influence on this hardware lock, right?

    So, supposing these two points are correct and taking is consideration that the exploit works, I have this question: is the cache being poisoned/written to without one actually writing to SMRAM (which might be irrelevant, since the cache will have precedence) OR simply changing the register will allow you to write to it?

    ReplyDelete
  8. @anonymous:

    You're correct, the exploit writes only to the cache, not to the actual DRAM (where the original SMM code is located). And, of course, this is just enough, because we're interested here in obtaining the SMM privileges, and we do get them, because the CPU executes our code from *cache* with SMM privileges.

    Should we be interested in actually modifying also the SMM handler (e.g. to create an SMM rootkit), we could use the simple trick described by Loic in his presentation [1] based on modifying the SMBASE register (one needs to be "in SMM" to be able to modify this register, of course).

    [1] http://cansecwest.com/csw09/csw09-duflot.pdf

    ReplyDelete