Here's a link to a talk on secure boot exploits etc. There's a bit on exploits which come in over the video aperture in order to flip the bits and get write permission on the secured stack, which I found interesting. https://m.youtube.com/watch?v=QDSlWa9xQuA -- Sent via K-9 Mail.
Hi is there anyone worked on Jboss.. On 30 Mar 2015 00:34, "R. Russell Reiter" <rreiter91@gmail.com> wrote:
Here's a link to a talk on secure boot exploits etc. There's a bit on exploits which come in over the video aperture in order to flip the bits and get write permission on the secured stack, which I found interesting.
https://m.youtube.com/watch?v=QDSlWa9xQuA
-- Sent via K-9 Mail. --- Talk Mailing List talk@gtalug.org http://gtalug.org/mailman/listinfo/talk
| From: R. Russell Reiter <rreiter91@gmail.com> | Here's a link to a talk on secure boot exploits etc. There's a bit on | exploits which come in over the video aperture in order to flip the bits | and get write permission on the secured stack, which I found | interesting. An interesting video, thanks. But it is nothing actually to do with video. It is all to do with the many different ways memory addresses get mapped in the x86 architecture and how each of them can create ways of addressing physical resources that need to be protected. Many protection mechnisms work on limiting address ranges and various address mappings, if not carefuly restricted themselves, can evade the primary protections. In the cases he mentioned. System Management Mode code and data is protected by some address restriction method. But if the apperture is set to point into the SMM area, certain ops can clobber SMM memory. The details are technical and I have not retained them in the few hours since I saw it. This just emphasizes that complexity is the enemy of security. All the systems that they attacked seemed complicated to me. Sometimes because of how the x86 has evolved as a set of interlocking hacks. I wonder if we can use the A20 gate to fool some of these checks. Now there is cruft.
On March 29, 2015 9:26:07 PM EDT, "D. Hugh Redelmeier" <hugh@mimosa.com> wrote:
| From: R. Russell Reiter <rreiter91@gmail.com>
| Here's a link to a talk on secure boot exploits etc. There's a bit on
| exploits which come in over the video aperture in order to flip the bits | and get write permission on the secured stack, which I found | interesting.
An interesting video, thanks.
But it is nothing actually to do with video. It is all to do with the many different ways memory addresses get mapped in the x86 architecture and how each of them can create ways of addressing physical resources that need to be protected.
Quite right. My poor choice of words describing the content of the video, might lead a reader to assume it relates to a viral type of exploit rather than an embedded feature/bug. Sorry bout that.
Many protection mechnisms work on limiting address ranges and various address mappings, if not carefuly restricted themselves, can evade the primary protections.
In the cases he mentioned. System Management Mode code and data is protected by some address restriction method. But if the apperture is set to point into the SMM area, certain ops can clobber SMM memory. The details are technical and I have not retained them in the few hours since I saw it.
I downloaded the presentation. Should make for good TTC fare, if you'll pardon the pun.
This just emphasizes that complexity is the enemy of security. All the systems that they attacked seemed complicated to me.
I think this is the point of machine learning which, if achieved, may serve to provide the fluidity required to approximate a human concept; common sense. Which I think we all know does not truly exist and yet seems to be a universal requirement of enterprise computing.
because of how the x86 has evolved as a set of interlocking hacks.
I wonder if we can use the A20 gate to fool some of these checks. Now there is cruft. --- Talk Mailing List talk@gtalug.org http://gtalug.org/mailman/listinfo/talk
-- Sent via K-9 Mail.
participants (3)
-
D. Hugh Redelmeier -
hemant gupta -
R. Russell Reiter