hello,
was reading this paper on ASLR, though it is user mode, was wondering
whether we have something similar for device drivers???
http://www.blackhat.com/presentations/bh-dc-07/Whitehouse/Presentation/bh-dc-07-Whitehouse.pdf
http://mail-index.netbsd.org/current-users/2008/07/18/msg003597.html –
sample example
Bedanto wrote:
hello,
was reading this paper on ASLR, though it is user mode, was wondering
whether we have something similar for device drivers???
There is essentially no point in doing so. Kernel code never loads at
its preferred address anyway, and if you have a process that can write
to kernel memory, your system is already lost.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
No, that is not what ASLR is about. It is a mitigation that reduces the chance of successful exploitation when there exists a bug that would allow you to, say, write to an arbitrary address within a particular program.
There is absolutely value in ASLR for driver code. As far as I know, though, the story is that the ntos base isn’t fixed as of Srv08/Vista SP1, but drivers don’t have their base addresses randomized. (Might be misremembering, in which case someone can correct me.)
Just because code doesn’t load at its preferred base address doesn’t mean that the load address is not going to be (relatively) predictable. Removing this predictability makes the chances of a reliable exploit attempt much harder under many circumstances.
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Tim Roberts
Sent: Thursday, December 04, 2008 9:31 PM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] ASLR
Bedanto wrote:
hello,
was reading this paper on ASLR, though it is user mode, was wondering
whether we have something similar for device drivers???
There is essentially no point in doing so. Kernel code never loads at
its preferred address anyway, and if you have a process that can write
to kernel memory, your system is already lost.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
NTDEV is sponsored by OSR
For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars
To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
>As far as I know, though, the story is that the ntos base isn’t fixed as of
Srv08/Vista SP1, but drivers don’t have their base addresses randomized.
(Might be misremembering, in which case someone can correct me.)
yes, you are right, there is a video on channel9 where mark cares to comment
on this issue. i wonder why MSFT didn’t do it for all drivers.
on the other hand, is 256 such a large number of places to try to figure out
where the code is? we have super fast CPUs not to add GPU parallelism being
used in general purpose computing…
On Thu, Dec 4, 2008 at 6:43 PM, Skywing wrote:
> No, that is not what ASLR is about. It is a mitigation that reduces the
> chance of successful exploitation when there exists a bug that would allow
> you to, say, write to an arbitrary address within a particular program.
>
> There is absolutely value in ASLR for driver code. As far as I know,
> though, the story is that the ntos base isn’t fixed as of Srv08/Vista SP1,
> but drivers don’t have their base addresses randomized. (Might be
> misremembering, in which case someone can correct me.)
>
> Just because code doesn’t load at its preferred base address doesn’t mean
> that the load address is not going to be (relatively) predictable. Removing
> this predictability makes the chances of a reliable exploit attempt much
> harder under many circumstances.
>
> - S
>
> -----Original Message-----
> From: xxxxx@lists.osr.com [mailto:
> xxxxx@lists.osr.com] On Behalf Of Tim Roberts
> Sent: Thursday, December 04, 2008 9:31 PM
> To: Windows System Software Devs Interest List
> Subject: Re: [ntdev] ASLR
>
> Bedanto wrote:
> > hello,
> >
> > was reading this paper on ASLR, though it is user mode, was wondering
> > whether we have something similar for device drivers???
>
> There is essentially no point in doing so. Kernel code never loads at
> its preferred address anyway, and if you have a process that can write
> to kernel memory, your system is already lost.
>
> –
> Tim Roberts, xxxxx@probo.com
> Providenza & Boekelheide, Inc.
>
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>
My guess would be backwards compatibility. One would imagine that it is likely a tough call to make that changes for potentially millions of people in an automagically-distributed service pack.
And yes, 256 randomization slots isn?t as big as it could be. It?s better than nothing, however. Where exploitation would have previously been just ?fire and forget?, that?s much less successful on a large scale when ASLR is thrown into the mix.
Note that you are generally not going to be able to retry again immediately in many circumstances, as a failed attempt is almost surely going to crash something.
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of A P
Sent: Thursday, December 04, 2008 10:33 PM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] ASLR
As far as I know, though, the story is that the ntos base isn’t fixed as of Srv08/Vista SP1, but drivers don’t have their base addresses randomized. (Might be misremembering, in which case someone can correct me.)
yes, you are right, there is a video on channel9 where mark cares to comment on this issue. i wonder why MSFT didn’t do it for all drivers.
on the other hand, is 256 such a large number of places to try to figure out where the code is? we have super fast CPUs not to add GPU parallelism being used in general purpose computing…
On Thu, Dec 4, 2008 at 6:43 PM, Skywing > wrote:
No, that is not what ASLR is about. It is a mitigation that reduces the chance of successful exploitation when there exists a bug that would allow you to, say, write to an arbitrary address within a particular program.
There is absolutely value in ASLR for driver code. As far as I know, though, the story is that the ntos base isn’t fixed as of Srv08/Vista SP1, but drivers don’t have their base addresses randomized. (Might be misremembering, in which case someone can correct me.)
Just because code doesn’t load at its preferred base address doesn’t mean that the load address is not going to be (relatively) predictable. Removing this predictability makes the chances of a reliable exploit attempt much harder under many circumstances.
- S
-----Original Message-----
From: xxxxx@lists.osr.commailto:xxxxx [mailto:xxxxx@lists.osr.commailto:xxxxx] On Behalf Of Tim Roberts
Sent: Thursday, December 04, 2008 9:31 PM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] ASLR
Bedanto wrote:
> hello,
>
> was reading this paper on ASLR, though it is user mode, was wondering
> whether we have something similar for device drivers???
There is essentially no point in doing so. Kernel code never loads at
its preferred address anyway, and if you have a process that can write
to kernel memory, your system is already lost.
–
Tim Roberts, xxxxx@probo.commailto:xxxxx
Providenza & Boekelheide, Inc.
—
NTDEV is sponsored by OSR
For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars
To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
—
NTDEV is sponsored by OSR
For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars
To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
— NTDEV is sponsored by OSR For our schedule of WDF, WDM, debugging and other seminars visit: http://www.osr.com/seminars To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer</mailto:xxxxx></mailto:xxxxx></mailto:xxxxx>
Yes, it’s called “loading the driver”. There is no fixed address where a
driver is loaded. I don’t know if the kernel ASLR mechanisms already in
place extend to drivers, but I think it’s pretty unlikely that a driver
loads at the same address on any two different machines.
joe
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Bedanto
Sent: Thursday, December 04, 2008 9:16 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] ASLR
hello,
was reading this paper on ASLR, though it is user mode, was wondering
whether we have something similar for device drivers???
http:c-07-Whitehouse.pdf>
http://www.blackhat.com/presentations/bh-dc-07/Whitehouse/Presentation/bh-dc
-07-Whitehouse.pdf
http:
http://mail-index.netbsd.org/current-users/2008/07/18/msg003597.html –
sample example
— NTDEV is sponsored by OSR For our schedule of WDF, WDM, debugging and
other seminars visit: http://www.osr.com/seminars To unsubscribe, visit the
List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
–
This message has been scanned for viruses and
dangerous content by http:</http:> MailScanner, and is
believed to be clean.</http:></http:>
Actually, not so very unlikely. Drivers will tend to load at the same order across every boot for many classes of drivers, which makes them likely to be at a particular base address always on a particular machine loadout. Especially for early-loading and ubiquitous stuff like drivers used for the boot process, those are quite likely to load at the same address across machines.
It often takes just one common reference point for many exploit scenarios.
Please do not downplay ASLR just because the preferred load address isn?t used. The assumption that simply because there isn?t a valid preferred load address that your actual load address won?t be highly predictable is not valid.
This is kind of the same thing as optimizing without actually doing the research as to whether there?s a problem or not. You really need to look at some actual data first.
I just picked two random unrelated systems (one running Srv08 x64 and the other Vista SP1 x64) and there are a whole bunch of drivers that were the same load addresses on these different systems. In fact, one system was even booted with full driver verifier and the other wasn?t and there were still a bunch of drivers at the same base addresses even though they had ?no valid preferred base address?. Many of these drivers were even early-boot in-box drivers that will be practically universally present on any Windows system.
I really cannot stress enough that dismissing the value of ASLR on the grounds of ?loader relocations? is really the wrong answer. Looking at actual data tells a different story.
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Joseph M. Newcomer
Sent: Thursday, December 04, 2008 11:36 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] ASLR
Yes, it?s called ?loading the driver?. There is no fixed address where a driver is loaded. I don?t know if the kernel ASLR mechanisms already in place extend to drivers, but I think it?s pretty unlikely that a driver loads at the same address on any two different machines.
joe
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Bedanto
Sent: Thursday, December 04, 2008 9:16 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] ASLR
hello,
was reading this paper on ASLR, though it is user mode, was wondering whether we have something similar for device drivers???
NetBSD + ASLR -- sample example
This message has been scanned for viruses and
dangerous content by MailScannerhttp:</http:>, and is
believed to be clean.
NTDEV is sponsored by OSR
For our schedule of WDF, WDM, debugging and other seminars visit:
To unsubscribe, visit the List Server section of OSR Online at ListServer/Forum
Opinions crumble in the presence of facts. I had experience that suggested
otherwise, but it is clearly an anomaly.
joe
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Skywing
Sent: Friday, December 05, 2008 1:07 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] ASLR
Actually, not so very unlikely. Drivers will tend to load at the same order
across every boot for many classes of drivers, which makes them likely to be
at a particular base address always on a particular machine loadout.
Especially for early-loading and ubiquitous stuff like drivers used for the
boot process, those are quite likely to load at the same address across
machines.
It often takes just one common reference point for many exploit scenarios.
Please do not downplay ASLR just because the preferred load address isn’t
used. The assumption that simply because there isn’t a valid preferred load
address that your actual load address won’t be highly predictable is not
valid.
This is kind of the same thing as optimizing without actually doing the
research as to whether there’s a problem or not. You really need to look at
some actual data first.
I just picked two random unrelated systems (one running Srv08 x64 and the
other Vista SP1 x64) and there are a whole bunch of drivers that were the
same load addresses on these different systems. In fact, one system was
even booted with full driver verifier and the other wasn’t and there were
still a bunch of drivers at the same base addresses even though they had “no
valid preferred base address”. Many of these drivers were even early-boot
in-box drivers that will be practically universally present on any Windows
system.
I really cannot stress enough that dismissing the value of ASLR on the
grounds of “loader relocations” is really the wrong answer. Looking at
actual data tells a different story.
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Joseph M. Newcomer
Sent: Thursday, December 04, 2008 11:36 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] ASLR
Yes, it’s called “loading the driver”. There is no fixed address where a
driver is loaded. I don’t know if the kernel ASLR mechanisms already in
place extend to drivers, but I think it’s pretty unlikely that a driver
loads at the same address on any two different machines.
joe
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Bedanto
Sent: Thursday, December 04, 2008 9:16 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] ASLR
hello,
was reading this paper on ASLR, though it is user mode, was wondering
whether we have something similar for device drivers???
http:c-07-Whitehouse.pdf>
http://www.blackhat.com/presentations/bh-dc-07/Whitehouse/Presentation/bh-dc
-07-Whitehouse.pdf
http:
http://mail-index.netbsd.org/current-users/2008/07/18/msg003597.html –
sample example
— NTDEV is sponsored by OSR For our schedule of WDF, WDM, debugging and
other seminars visit: http://www.osr.com/seminars To unsubscribe, visit the
List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
–
This message has been scanned for viruses and
dangerous content by http:</http:> MailScanner, and is
believed to be clean.
—
NTDEV is sponsored by OSR
For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars
To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
—
NTDEV is sponsored by OSR
For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars
To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
–
This message has been scanned for viruses and
dangerous content by http:</http:> MailScanner, and is
believed to be clean.</http:></http:>
Skywing wrote:
No, that is not what ASLR is about. It is a mitigation that reduces the chance of successful exploitation when there exists a bug that would allow you to, say, write to an arbitrary address within a particular program.
Yes, I know this. And if your machine has code in kernel mode that can
exploit this, then it’s already “game over”. ASLR isn’t going to help.
There is absolutely value in ASLR for driver code.
I remain dubious.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
The whole *point* of ASLR is to mitigate in the scenario where someone’s got control of an address to write to, or the instruction pointer, and wants to find a “safe”/“known” location that can be leveraged to run arbitrary code. It is certainly not a panacea, but it’s the difference between writing a fire-and-forget wormable exploit and a DoS, in many cases, for example.
There is really no difference here as to whether the current mode is KernelMode or UserMode with respect to how this stuff works from an exploitation perspective. There is no magical reason why it is somehow less important for kernel mode than user mode.
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Tim Roberts
Sent: Friday, December 05, 2008 12:22 PM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] ASLR
Skywing wrote:
No, that is not what ASLR is about. It is a mitigation that reduces the chance of successful exploitation when there exists a bug that would allow you to, say, write to an arbitrary address within a particular program.
Yes, I know this. And if your machine has code in kernel mode that can
exploit this, then it’s already “game over”. ASLR isn’t going to help.
There is absolutely value in ASLR for driver code.
I remain dubious.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
NTDEV is sponsored by OSR
For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars
To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer