Re: How does kernel raise the exception? (solved)

NTDEV
1

Just for anyone who is interested:

Finally I found the reason, inside the MmAccessFault(), the ExecuteOptions
was used to determine it’s an normal overflow or not. If the ExecuteOption
was set to 2, an 0xC0000005 exception will be raised to this application.
But how this ExecuteOption was set? well, it’s set during process
initialization, an undocumented registry key was just for this purpose, for
example: MSO.DLL is used by Office applications, it was in the Nx “white
list”, all applications loaded the MSO.DLL will bypass the Nx checking! I
have verified, just simply LoadLibrary( “mso.dll” ) in my test application,
then execute the codes from stack, the Nx won’t be triggered! This seems
like a security hole on MS’s Nx solution? :slight_smile: Anyway I have achieve my
researching goal.

thanks,

AFei

---------------------------------- original post:
Refer to my last post, for some reason, some applications won’t raise the
exception when running codes in stack (exp: vs.net), kernel must know how to
decide this, I’m still digging on this.

2

AFei wrote:

Finally I found the reason, inside the MmAccessFault(), the ExecuteOptions
was used to determine it’s an normal overflow or not. If the ExecuteOption
was set to 2, an 0xC0000005 exception will be raised to this application.
But how this ExecuteOption was set? well, it’s set during process
initialization, an undocumented registry key was just for this purpose, for
example: MSO.DLL is used by Office applications, it was in the Nx “white
list”, all applications loaded the MSO.DLL will bypass the Nx checking! I
have verified, just simply LoadLibrary( “mso.dll” ) in my test application,
then execute the codes from stack, the Nx won’t be triggered! This seems
like a security hole on MS’s Nx solution? :slight_smile:

Hell, yes, it is. I’m not sure why you have a smiley there. That
unethical little back door renders the entire NX solution useless.
Spencer the Katt at eWeek would be interested in this.

Of course, ph@tz0 down at the Legion of d00m, who spends his evenings
writing viruses, is also going to be interested in it.

The folks in the XP group should be ashamed for putting this in, the the
folks in the Office group should be ashamed for needing it.

–

3

Okay, I’m smiling that MS puts in more features together with more holes.
what I guess is they don’t want to make a “big” change on their existed
products like office, and they were doing things rejected by Nx themselves,
so a back door is necessary to give their own applications a higher
priority. A lazy design caused this problem. Another consideration might be,
tons of 3rd applications doing the same thing which MS have to support their
unethical programming. Of course, I don’t want this hole was used by virus
writer, maybe I should report this to MS or some security groups. Any
suggestions are welcome.

AFei

“Tim Roberts” wrote in message news:xxxxx@ntdev…
> AFei wrote:
>
> >Finally I found the reason, inside the MmAccessFault(), the
ExecuteOptions
> >was used to determine it’s an normal overflow or not. If the
ExecuteOption
> >was set to 2, an 0xC0000005 exception will be raised to this application.
> >But how this ExecuteOption was set? well, it’s set during process
> >initialization, an undocumented registry key was just for this purpose,
for
> >example: MSO.DLL is used by Office applications, it was in the Nx “white
> >list”, all applications loaded the MSO.DLL will bypass the Nx checking! I
> >have verified, just simply LoadLibrary( “mso.dll” ) in my test
application,
> >then execute the codes from stack, the Nx won’t be triggered! This seems
> >like a security hole on MS’s Nx solution? :slight_smile:
> >
> >
>
> Hell, yes, it is. I’m not sure why you have a smiley there. That
> unethical little back door renders the entire NX solution useless.
> Spencer the Katt at eWeek would be interested in this.
>
> Of course, ph@tz0 down at the Legion of d00m, who spends his evenings
> writing viruses, is also going to be interested in it.
>
> The folks in the XP group should be ashamed for putting this in, the the
> folks in the Office group should be ashamed for needing it.
>
> –
> - Tim Roberts, xxxxx@probo.com
> Providenza & Boekelheide, Inc.
>
>

4

Okay, I’m smiling that MS puts in more features together with more holes.
what I guess is they don’t want to make a “big” change on their existed
products like office, and they were doing things rejected by Nx themselves,
so a back door is necessary to give their own applications a higher
priority. A lazy design caused this problem. Another consideration might be,
tons of 3rd applications doing the same thing which MS have to support their
unethical programming. Of course, I don’t want this hole was used by virus
writer, maybe I should report this to MS or some security groups. Any
suggestions are welcome.

AFei

5

The NX solution that we shipped was intended to catch existing malware and
unintended screwups. If you read the press releases carefully, they never
say that it’s a security feature. They always call it a reliability
feature. Other people’s reinterpretation of those press releases called it
a security feature, though, which significantly confuses the situation.

The bottom line is that no solution in this space could possibly be
bulletproof without busting a huge number of apps. And compatibility with
existing software is Windows’ number one feature.

By the way, this is not my area of work. I don’t intend to try to justify
these decsions and I probably won’t bother to engage in the arguments that
this will devolve into. If you need more information and/or you absolutely
must argue the subject, I will forward your e-mail on to the Program
Managers who are involved. They may decide to respond.

–
Jake Oshins
Windows Kernel Group

This posting is provided “AS IS” with no warranties, and confers no rights.

“AFei” wrote in message news:xxxxx@ntdev…
> Okay, I’m smiling that MS puts in more features together with more holes.
> what I guess is they don’t want to make a “big” change on their existed
> products like office, and they were doing things rejected by Nx
> themselves,
> so a back door is necessary to give their own applications a higher
> priority. A lazy design caused this problem. Another consideration might
> be,
> tons of 3rd applications doing the same thing which MS have to support
> their
> unethical programming. Of course, I don’t want this hole was used by virus
> writer, maybe I should report this to MS or some security groups. Any
> suggestions are welcome.
>
> AFei
>
>
>

6

I’m fine with it and thanks for the clarification, on my point of view, Nx
is a very good security feature provided by hardware, it is better if OS can
enforce this down to all applications, force the applications (include
office) to change their unethical programming, (maybe start from Longhorn.),
I knew it’s not enough to fighting with virus and trojans, at least it will
cause some trouble to them. Just my opinions.

Rgds,

AFei

“Jake Oshins” wrote in message
news:xxxxx@ntdev…
> The NX solution that we shipped was intended to catch existing malware and
> unintended screwups. If you read the press releases carefully, they never
> say that it’s a security feature. They always call it a reliability
> feature. Other people’s reinterpretation of those press releases called
it
> a security feature, though, which significantly confuses the situation.
>
> The bottom line is that no solution in this space could possibly be
> bulletproof without busting a huge number of apps. And compatibility with
> existing software is Windows’ number one feature.
>
> By the way, this is not my area of work. I don’t intend to try to justify
> these decsions and I probably won’t bother to engage in the arguments that
> this will devolve into. If you need more information and/or you
absolutely
> must argue the subject, I will forward your e-mail on to the Program
> Managers who are involved. They may decide to respond.
>
> –
> Jake Oshins
> Windows Kernel Group
>
> This posting is provided “AS IS” with no warranties, and confers no
rights.
>
>
> “AFei” wrote in message news:xxxxx@ntdev…
> > Okay, I’m smiling that MS puts in more features together with more
holes.
> > what I guess is they don’t want to make a “big” change on their existed
> > products like office, and they were doing things rejected by Nx
> > themselves,
> > so a back door is necessary to give their own applications a higher
> > priority. A lazy design caused this problem. Another consideration might
> > be,
> > tons of 3rd applications doing the same thing which MS have to support
> > their
> > unethical programming. Of course, I don’t want this hole was used by
virus
> > writer, maybe I should report this to MS or some security groups. Any
> > suggestions are welcome.
> >
> > AFei
> >
> >
> >
>
>
>

7

The NX implementation is a security feature of XP SP2.

Specifically, NX prevents the execution of code marked as non-executable.
Some malware is known to execute code from non-executable locations during
attack. Additionally, NX forces developers to ensure they’re properly
marking all code (including JITed code) as executable. It’s these scenarios
that NX is designed for.

Jake is correct-application compatibility is a very important Windows
feature. We know it is important to our customers to be able to use their
older programs when upgrading to a new OS or updating to the latest service
pack.

The NX implementation addresses compatibility partially through the
mechanism that is described above. There are a limited set of libraries
that are known to have compatibility issues with NX. Instead of preventing
the application dependent upon the library from running, Windows
automatically disables NX for the application.

There are some scenarios where automatically disabling NX makes more sense
than putting users through the pain of their applications crashing
continually. It’s a balance between compatibility and security.

Note that this process of automatically disabling NX is carefully targeted
to a limited set of libraries with specific characteristics such as version,
manufacturer and link date. In the MSO example, only several versions of
MSO cause NX to be automatically disabled; later versions do not cause NX to
automatically be disabled. Also, there are non-Microsoft libraries in the
list.

Is this process of automatically disabling NX based on loading of a library
a Windows vulnerability? No. If your attack can get enough code running to
call LoadLibrary() on MSO.DLL or another library in this list to disable NX,
then you’re already past the point where NX would be useful in helping to
prevent your exploit.

Finally, a system administrator can turn off this automatic disabling-NX
behavior by adding “/noexecute=alwayson” to the boot entry.

Pat Stemen
Program Manager, Windows Kernel Platform Group

This posting is provided “AS IS” with no warranties, and confers no rights.

“AFei” wrote in message news:xxxxx@ntdev…
>
> I’m fine with it and thanks for the clarification, on my point of view, Nx
> is a very good security feature provided by hardware, it is better if OS
> can
> enforce this down to all applications, force the applications (include
> office) to change their unethical programming, (maybe start from
> Longhorn.),
> I knew it’s not enough to fighting with virus and trojans, at least it
> will
> cause some trouble to them. Just my opinions.
>
> Rgds,
>
> AFei
>
> “Jake Oshins” wrote in message
> news:xxxxx@ntdev…
>> The NX solution that we shipped was intended to catch existing malware
>> and
>> unintended screwups. If you read the press releases carefully, they
>> never
>> say that it’s a security feature. They always call it a reliability
>> feature. Other people’s reinterpretation of those press releases called
> it
>> a security feature, though, which significantly confuses the situation.
>>
>> The bottom line is that no solution in this space could possibly be
>> bulletproof without busting a huge number of apps. And compatibility
>> with
>> existing software is Windows’ number one feature.
>>
>> By the way, this is not my area of work. I don’t intend to try to
>> justify
>> these decsions and I probably won’t bother to engage in the arguments
>> that
>> this will devolve into. If you need more information and/or you
> absolutely
>> must argue the subject, I will forward your e-mail on to the Program
>> Managers who are involved. They may decide to respond.
>>
>> –
>> Jake Oshins
>> Windows Kernel Group
>>
>> This posting is provided “AS IS” with no warranties, and confers no
> rights.
>>
>>
>> “AFei” wrote in message news:xxxxx@ntdev…
>> > Okay, I’m smiling that MS puts in more features together with more
> holes.
>> > what I guess is they don’t want to make a “big” change on their existed
>> > products like office, and they were doing things rejected by Nx
>> > themselves,
>> > so a back door is necessary to give their own applications a higher
>> > priority. A lazy design caused this problem. Another consideration
>> > might
>> > be,
>> > tons of 3rd applications doing the same thing which MS have to support
>> > their
>> > unethical programming. Of course, I don’t want this hole was used by
> virus
>> > writer, maybe I should report this to MS or some security groups. Any
>> > suggestions are welcome.
>> >
>> > AFei
>> >
>> >
>> >
>>
>>
>>
>
>
>

8

Hi Pat, I agree with you on most of the words, I’m a security application
developer myself, we all know balancing between compatibility and security
is not easy, but based on my discovery, I disagree some of your points,
maybe I was wrong because my understanding of kernel is limited, just
correct me if anything was wrong. For the MSO example, not only MS libraries
are in the list, at least I saw several Norton libraries there. To approve
the conception, my test application did the loadlibrary, but the real risk
is, those not Nx-ed applications can be picked as the attacking target
without triggering the Nx protection, if some common libraries are in the
list (exp: vb run time library), too many 3rd party applications will link
to it and which means these applications are “open” for being attacked. So
my suggestion is to change to a more secure way, Nx is a very good feature
and and it should be pushed to the front desk.
By the way, I’m afraid this is a little bit off topic, we can discuss more
privately if you want: fhuang4555 at hotmail dot com.

Just my 2 cents and thanks.

AFei

“Pat Stemen [MSFT]” wrote in message
news:xxxxx@ntdev…
> The NX implementation is a security feature of XP SP2.
>
> Specifically, NX prevents the execution of code marked as non-executable.
> Some malware is known to execute code from non-executable locations during
> attack. Additionally, NX forces developers to ensure they’re properly
> marking all code (including JITed code) as executable. It’s these
scenarios
> that NX is designed for.
>
> Jake is correct-application compatibility is a very important Windows
> feature. We know it is important to our customers to be able to use their
> older programs when upgrading to a new OS or updating to the latest
service
> pack.
>
> The NX implementation addresses compatibility partially through the
> mechanism that is described above. There are a limited set of libraries
> that are known to have compatibility issues with NX. Instead of
preventing
> the application dependent upon the library from running, Windows
> automatically disables NX for the application.
>
> There are some scenarios where automatically disabling NX makes more sense
> than putting users through the pain of their applications crashing
> continually. It’s a balance between compatibility and security.
>
> Note that this process of automatically disabling NX is carefully targeted
> to a limited set of libraries with specific characteristics such as
version,
> manufacturer and link date. In the MSO example, only several versions of
> MSO cause NX to be automatically disabled; later versions do not cause NX
to
> automatically be disabled. Also, there are non-Microsoft libraries in the
> list.
>
> Is this process of automatically disabling NX based on loading of a
library
> a Windows vulnerability? No. If your attack can get enough code running
to
> call LoadLibrary() on MSO.DLL or another library in this list to disable
NX,
> then you’re already past the point where NX would be useful in helping to
> prevent your exploit.
>
> Finally, a system administrator can turn off this automatic disabling-NX
> behavior by adding “/noexecute=alwayson” to the boot entry.
>
> Pat Stemen
> Program Manager, Windows Kernel Platform Group
> ------------------------
> This posting is provided “AS IS” with no warranties, and confers no
rights.
>
>
>
> “AFei” wrote in message news:xxxxx@ntdev…
> >
> > I’m fine with it and thanks for the clarification, on my point of view,
Nx
> > is a very good security feature provided by hardware, it is better if OS
> > can
> > enforce this down to all applications, force the applications (include
> > office) to change their unethical programming, (maybe start from
> > Longhorn.),
> > I knew it’s not enough to fighting with virus and trojans, at least it
> > will
> > cause some trouble to them. Just my opinions.
> >
> > Rgds,
> >
> > AFei
> >
> > “Jake Oshins” wrote in message
> > news:xxxxx@ntdev…
> >> The NX solution that we shipped was intended to catch existing malware
> >> and
> >> unintended screwups. If you read the press releases carefully, they
> >> never
> >> say that it’s a security feature. They always call it a reliability
> >> feature. Other people’s reinterpretation of those press releases
called
> > it
> >> a security feature, though, which significantly confuses the situation.
> >>
> >> The bottom line is that no solution in this space could possibly be
> >> bulletproof without busting a huge number of apps. And compatibility
> >> with
> >> existing software is Windows’ number one feature.
> >>
> >> By the way, this is not my area of work. I don’t intend to try to
> >> justify
> >> these decsions and I probably won’t bother to engage in the arguments
> >> that
> >> this will devolve into. If you need more information and/or you
> > absolutely
> >> must argue the subject, I will forward your e-mail on to the Program
> >> Managers who are involved. They may decide to respond.
> >>
> >> –
> >> Jake Oshins
> >> Windows Kernel Group
> >>
> >> This posting is provided “AS IS” with no warranties, and confers no
> > rights.
> >>
> >>
> >> “AFei” wrote in message news:xxxxx@ntdev…
> >> > Okay, I’m smiling that MS puts in more features together with more
> > holes.
> >> > what I guess is they don’t want to make a “big” change on their
existed
> >> > products like office, and they were doing things rejected by Nx
> >> > themselves,
> >> > so a back door is necessary to give their own applications a higher
> >> > priority. A lazy design caused this problem. Another consideration
> >> > might
> >> > be,
> >> > tons of 3rd applications doing the same thing which MS have to
support
> >> > their
> >> > unethical programming. Of course, I don’t want this hole was used by
> > virus
> >> > writer, maybe I should report this to MS or some security groups. Any
> >> > suggestions are welcome.
> >> >
> >> > AFei
> >> >
> >> >
> >> >
> >>
> >>
> >>
> >
> >
> >
>
>
>