A few quick updates
It's been a little while since we've updated, but that doesn't mean that we haven't been busy. Right now we're working on some changes to alpha release 4. The most important changes will include major enhancements to some of the core protocol libraries. We're also planning on rolling out a Windows installer this time around so that people who use Windows can begin to try out the 3.0 version of the framework. Aside from these things, we've also broken ground on a completely revamped interface for msfweb. This new interface won't be included in r4. We've also been busy working on a few other projects. Here are a few noteworthy items:
Uninformed just published the fourth volume of the Uninformed Journal.
I've updated the system call table on the Metasploit website to include system call numbers for Vista Beta 2. The good news is that NtAccessCheckAndAuditAlarm hasn't changed system call numbers! This means that the system call based egghunt for Windows will still work fine.
Other random interesting news includes the fact Vista Beta 2 now has an implementation of ASLR. This is a great step forward in terms of security, as ASLR is a good complement to NX. While Microsoft's implementation is limited to 8 bits of entropy in the 3rd octet, it's enough to shift the odds of a successful attack. One limitation of the ASLR implementation included in Vista is that it does not have a mechanism that allows it to help prevent against local privilege escalations, such as by randomizing images to different locations based on privilege separations. There is a good reason for not doing this, though, and it's centered around the memory overhead associated with having to apply relocations once per-randomization.
From what I've analyzed of Vista's implementation, relocations are applied to the physical pages that are associated with the section object that is created for an image file mapping during a call to nt!MmCreateSection. In this manner, relocations are applied prior to the first time the image is mapped. Subsequent mappings of the image will share the same section object and, as such, will share the same set of physical pages that the relocations have been applied to. These mappings will all attempt to use the new base address that has been assigned to the image. Overall, the approach taken is very good, but it would indeed incur a non-trivial memory overhead if the operation were to be performed multiple times per-image, such as by randomizing ntdll.dll to a different location between LocalSystem vs. JoeBob. The benefits, however, may out weigh the memory overhead concerns, especially as we move toward the future.
Also, keep in mind that in order to implement randomizing along privilege separations, Microsoft may only need to randomize a smaller subset of images to another base address. The reason only a subset would need to be randomized is due to the fact that system processes will tend to rely on fewer DLLs when compared to user processes. However, as an exception to that point, processes like svchost, which may also run as LocalSystem, are likely to indirectly depend on a larger set of images. There are also some other technical problems surrounding the randomization certain images, like ntdll.dll. These few DLLs (ntdll, kernel32, and user32) are assumed by the kernel (and user-mode) to be at the same address in every process for different reasons. There are trivial solutions to these problems, however, and Microsoft is best fit to implement them given their source-level perspective.
Anyway, that's a bit more about ASLR than I intended to get into. As for Metasploit, we should be posting some more updates here in the near future about the r4 release. Stay tuned.
Uninformed just published the fourth volume of the Uninformed Journal.
I've updated the system call table on the Metasploit website to include system call numbers for Vista Beta 2. The good news is that NtAccessCheckAndAuditAlarm hasn't changed system call numbers! This means that the system call based egghunt for Windows will still work fine.
Other random interesting news includes the fact Vista Beta 2 now has an implementation of ASLR. This is a great step forward in terms of security, as ASLR is a good complement to NX. While Microsoft's implementation is limited to 8 bits of entropy in the 3rd octet, it's enough to shift the odds of a successful attack. One limitation of the ASLR implementation included in Vista is that it does not have a mechanism that allows it to help prevent against local privilege escalations, such as by randomizing images to different locations based on privilege separations. There is a good reason for not doing this, though, and it's centered around the memory overhead associated with having to apply relocations once per-randomization.
From what I've analyzed of Vista's implementation, relocations are applied to the physical pages that are associated with the section object that is created for an image file mapping during a call to nt!MmCreateSection. In this manner, relocations are applied prior to the first time the image is mapped. Subsequent mappings of the image will share the same section object and, as such, will share the same set of physical pages that the relocations have been applied to. These mappings will all attempt to use the new base address that has been assigned to the image. Overall, the approach taken is very good, but it would indeed incur a non-trivial memory overhead if the operation were to be performed multiple times per-image, such as by randomizing ntdll.dll to a different location between LocalSystem vs. JoeBob. The benefits, however, may out weigh the memory overhead concerns, especially as we move toward the future.
Also, keep in mind that in order to implement randomizing along privilege separations, Microsoft may only need to randomize a smaller subset of images to another base address. The reason only a subset would need to be randomized is due to the fact that system processes will tend to rely on fewer DLLs when compared to user processes. However, as an exception to that point, processes like svchost, which may also run as LocalSystem, are likely to indirectly depend on a larger set of images. There are also some other technical problems surrounding the randomization certain images, like ntdll.dll. These few DLLs (ntdll, kernel32, and user32) are assumed by the kernel (and user-mode) to be at the same address in every process for different reasons. There are trivial solutions to these problems, however, and Microsoft is best fit to implement them given their source-level perspective.
Anyway, that's a bit more about ASLR than I intended to get into. As for Metasploit, we should be posting some more updates here in the near future about the r4 release. Stay tuned.
posted by skape at 6:29 PM
2 Comments:
Their seems to be some suggestions on the web that if the vulnerable function lies inside the randomized dll, known instructions could be reached by using offsets instead of full addresses. does the microsoft implementation of ASLR protect against these sort of attacks?
Read More
No, Microsoft's implementation does not protect against partial address overwrites. While this is a valid technique that can be used to bypass ASLR, its applicability is dependent on the vulnerability in question. For instance, given a typical return address overwrite, most attackers will overwrite the return address with the location of a jmp esp instruction. This means that the area of the stack immediately following the return address (or potentially its arguments) will be used to store attacker controlled executable code. However, when doing a partial address overwrite, the attacker would typically not have the ability to write past where the return address resides on the stack. This doesn't make exploitation impossible, but it does mean that you can't simply find a relative offset to a jmp esp instruction. You must find some way to place your buffer prior to the return address and find an instruction or series of instructions that are relative to the return address that can be useful for the purposes of redirecting code once the function returns.
That's not to downplay the problem though, as it's certainly a valid concern. There a number of problems involved in efficiently fixing the partial address overwrite condition. There are a number of inefficient approaches that could be taken. Given Microsoft's source-level perspective, I can think of some ways that they might be able to tackle the problem. My guess is that this will remain an unsolved problem, though.
Post a Comment
Links to this post:
Create a Link
<< Home