Anyone who wants to blue-screen on XP SP2 right from the user mode, regardless of the account privileges, can try the following lines:
////////// UNICODE_STRING str={8,10,L"test"}; ULONG x,args[]={0x11111111,0x11111111,(ULONG)&str};
typedef NTSTATUS (__stdcall*func)(NTSTATUS, ULONG,ULONG,PULONG,UINT,PULONG) ;
func NtRaiseHardError=(func)GetProcAddress(GetModuleHandle("ntdll.dll"), "NtRaiseHardError");
NtRaiseHardError(0x50000018,3,4,args,1,&x);
/////
This is just one more proof of naiveity of the assumption that everything is OK as long as you run on restricted account. As you can see, there is no problem with crashing the system right from the user mode on the restricted account whatsoever. I don't exclude the possibility that there is some other yet unknown bug that may allow the attacker to elevate his/her privileges - after all, no one and nothing is perfect
Regards
Anton Bassov
"); //--> Reply
> allow the attacker to elevate his/her privileges - > after all, no one and nothing is perfect
If however you mean that it is the application crashing, not XP, then you need to be more specific.
I am afraid you have missed the point. According to Microsoft, user-mode applications haven't got a slightest chance of crashing the system, because everything that they pass to the kernel-mode code gets validated. However, if you run the above lines, you will see that this is not the case. In other words, this is just a bug - in the above example the system "forgets" to validate parameters, so that anyone who wants to blue-screen right from the user mode can do it simply by supplying the "right" parameters.
When it comes to privilege elevation, all "buffer overflow" and "shatter" attacks rely upon system's failure to validate parameters. In order to handle such attacks, Microsoft claims to have introduced thorough parameter validation - checking pointers that are passed to other applications, checking array bounds and the amount of data that gets passed, etc. The above example just illustrates that parameter validation is not as thorough as Microsoft claims, so that,probably, some "buffer overflow" and "shatter" attacks may still be successfull, despite all parameter checking.
I believe this particular crash has been fixed in Win2003 SP1.
-- This posting is provided "AS IS" with no warranties, and confers no rights.
- Hide quoted text - - Show quoted text -
> Anyone who wants to blue-screen on XP SP2 right from the user mode, > regardless of the account privileges, can try the following lines:
> ////////// > UNICODE_STRING str={8,10,L"test"}; > ULONG x,args[]={0x11111111,0x11111111,(ULONG)&str};
> typedef NTSTATUS (__stdcall*func)(NTSTATUS, > ULONG,ULONG,PULONG,UINT,PULONG) > ;
> func NtRaiseHardError=(func)GetProcAddress(GetModuleHandle("ntdll.dll"), > "NtRaiseHardError");
> NtRaiseHardError(0x50000018,3,4,args,1,&x);
> /////
> This is just one more proof of naiveity of the assumption that everything > is > OK as long as you run on restricted account. As you can see, there is no > problem with crashing the system right from the user mode on the > restricted > account whatsoever. I don't exclude the possibility that there is some > other > yet unknown bug that may allow the attacker to elevate his/her > privileges - > after all, no one and nothing is perfect
Maybe on xp sp2 it causes crush but my win2k3 is alive after running this code. I see
7C82ED50 mov edx,esp 7C82ED52 sysenter
in NtRaiseHardError so it goes to SDT directly ...
-- Vladimir manage content: http://www.infostoria.com/ blog: http://thespoke.net/blogs/vladimir_scherbina/
As it follows from the message above, W2K3 SP1 has fixed it In fact, I thought that this bug was specific only to XP SP2, so that I was quite surprized to learn that different flavours of Windows may be crashed this way
> As it follows from the message above, W2K3 SP1 has fixed it > In fact, I thought that this bug was specific only to XP SP2, so that I > was > quite surprized to learn that different flavours of Windows may be crashed > this way
> Regards
> Anton Bassov
At least now we have some "documentary proof" that we will be able to present the next time we have to deal with ridiculous claims that, as long as you run on the resticted account, your system is perfectly safe. As I can see, there are plenty of people who just don't seem to have enough "grayware" to understand that,first, MSFT code may have its bugs, and, second, not all exploitable bugs that are discovered get reported. Let's face it - if you are malware writer, would you report the exploitable bug that you have discovered, or would you just exploit it without telling anyone???? I am almost 100% sure that there is this or that way to elevate privileges - after all, if some exploit is not known to general public, it does not necessarily mean that your system is 100% safe, as some posters claim
> At least now we have some "documentary proof" that we will be able to > present the next time we have to deal with ridiculous claims that, as long > as you run on the resticted account, your system is perfectly safe. As I > can > see, there are plenty of people who just don't seem to have enough > "grayware" to understand that,first, MSFT code may have its bugs, and, > second, not all exploitable bugs that are discovered get reported. Let's > face it - if you are malware writer, would you report the exploitable bug > that you have discovered, or would you just exploit it without telling > anyone???? I am almost 100% sure that there is this or that way to elevate > privileges - after all, if some exploit is not known to general public, it > does not necessarily mean that your system is 100% safe, as some posters > claim
I would not use such logic. First of all, not bugs are exploitable (the one we discuss here is just one example). Second, and even more important, it really depends on what we call a bug. As they say, all great discoveries are always made accidentally. I am afraid here we deal with more or less the same situation.
For example, I don't think that someone was spending sleepless nights, trying to do buffer overflow. Appearently, someone just accidentally overwrote the return address, jumped to the middle of nowhere, got surprized with the result, debugged the problem... and then realized that the same thing can be done in more meaningfull way.
In other words, OS designers just have no way of knowing what and how may get exploited, and hackers are normally in exactly the same position as well - they are going to find vulnerability as a matter of accident, rather than by intentional search(which,in most cases,proves to be fruitless). Therefore, sometimes you would not say that some piece of code is buggy or vulnerable until it gets exploited
To summarize, I think that relying upon some supposedly invincible system-provided security feature is rather naive approach
> I would not use such logic. First of all, not bugs are exploitable > (the one we discuss here is just one example). > Second, and even more important, it really depends on what we call a > bug. As they say, all great discoveries are always made accidentally. > I am afraid here we deal with more or less the same situation.
> For example, I don't think that someone was spending sleepless nights, > trying to do buffer overflow. Appearently, someone just accidentally > overwrote the return address, jumped to the middle of nowhere, got > surprized with the result, debugged the problem... and then realized > that the same thing can be done in more meaningfull way.
> To summarize, I think that relying upon some supposedly invincible > system-provided security feature is rather naive approach
-cd
What I actually meant is new TYPES (!!!) of attack - this is what normally gets discovered accidentally, so that you just cannot foresee things like that. Once you know what to do, you can already systematically probe all places that you believe may be of interest, i.e. something what Mark Russinovich did. However, at this point, it is already possible to make provisions against this particular type of attack (because it is already known), so that the code that does not make such provisions can already qualify for being buggy
AFAIK there are about 1.5-2 testers for developer in MSFT ( as once Bill Gates stand that MSFT's is huge test s/w house ) and they 're developing code to test others ( OS ) code trying to find those types, you wrote about Arkady
> What I actually meant is new TYPES (!!!) of attack - this is what normally > gets discovered accidentally, so that you just cannot foresee things like > that. Once you know what to do, you can already systematically probe all > places that you believe may be of interest, i.e. something what Mark > Russinovich did. However, at this point, it is already possible to make > provisions against this particular type of attack (because it is already > known), so that the code that does not make such provisions can already > qualify for being buggy
"Carl Daniel [VC++ MVP]" <cpdaniel_remove_this_and_nos...@mvps.org.nospam> wrote in
> I'm not so sure about that. I recall an article on sysinternals.com where > Mark R. describes writing a program to systematically attack every single > entry point in ntdll.dll. I'm sure mal-intentioned hackers have done the > same, and do the same on an ongoing basis.
-- Don Burn (MVP, Windows DDK) Windows 2k/XP/2k3 Filesystem and Driver Consulting Remove StopSpam from the email to reply
As far as I know, "buffer overflow" has been first done on UNIX as well(although this system is supposed to be much more reliable than Windows). In other words, nothing is perfect, so that I am sure Vista is going to have quite a few security "openings" - despite all MSFT claims
Buffer overflow/overrun is essentially a bug, right? I think Microsoft was not as careful in the past but they have been forced to be more professional about providing quality code. Obviosuly if they were too sloppy then Linux would be even more popular.
Since Windows is in use as much as it is indicates that it is trusted. Some people in this thread are trying to say that Windows is not reliable, but if it was as vulnerable as people say, then it would not be trusted as much as it is. Windows is potentially vulnerable, but the fact that it is not expoited more than it is indicates it is not as vulnerable as some people indicate.
Microsoft has become aware of the need to be careful and is obviously implementing that requirement in their current developments.
> As far as I know, "buffer overflow" has been first done on UNIX as > well(although this system is supposed to be much more reliable than > Windows).
> This is just one more proof of naiveity
Microsoft representative Pavel provided us with the preferred response.
Do you know of any (just one is enough) example of Windows NT/2000/XP and above working as designed that allows a user-mode application with only normal privileges to crash the system?
Your point is that Windows has bugs. That is a valid point, but any implication that Windows is designed in a manner that allows system crashes is inaccurate. As far as bugs are concerned, the issue is the quantity that are potential exploits and the efforts that Microsoft makes to fix them when they are discovered.
To the extent that a bug is exploited maliciously, that is obviously a problem.
> I am afraid you have missed the point. According to Microsoft, user-mode > applications haven't got a slightest chance of crashing the system, > because > everything that they pass to the kernel-mode code gets validated. However, > if you run the above lines, you will see that this is not the case. In > other > words, this is just a bug - in the above example the system "forgets" to > validate parameters, so that anyone who wants to blue-screen right from > the > user mode can do it simply by supplying the "right" parameters.
d
-- Please do not send e-mail directly to this alias. this alias is for newsgroup purposes only. This posting is provided "AS IS" with no warranties, and confers no rights.
> Buffer overflow/overrun is essentially a bug, right? I think Microsoft was > not as careful in the past but they have been forced to be more > professional about providing quality code. Obviosuly if they were too > sloppy then Linux would be even more popular.
> Since Windows is in use as much as it is indicates that it is trusted. > Some people in this thread are trying to say that Windows is not reliable, > but if it was as vulnerable as people say, then it would not be trusted as > much as it is. Windows is potentially vulnerable, but the fact that it is > not expoited more than it is indicates it is not as vulnerable as some > people indicate.
> Microsoft has become aware of the need to be careful and is obviously > implementing that requirement in their current developments.
> "anton bassov" <x...@yyy.com> wrote in message > news:524fe0feb39f464a88e15b08c5e82474@ureader.com...
>> As far as I know, "buffer overflow" has been first done on UNIX as >> well(although this system is supposed to be much more reliable than >> Windows).
I am afraid you just don't really know what you are talking about. Why do you make this ridiculous statement about malicious attack at the time of BSOD again and again???? After all, these two are totally independent things -I really don't know what makes you believe they may be somehow related.
Now look at your following statement: ///// Do you know of any (just one is enough) example of Windows NT/2000/XP and above working as designed that allows a user-mode application with only normal privileges to crash the system? /////
This thread has been started off with such example, and this is what we discuss here. How are we supposed to react to your question?????
I am afraid you have posted your messages for the sole purpose of posting them - they don't ask any questions that are relevant to this particular discussion
You were the one who said "I don't exclude the possibility that there is some other yet unknown bug that may allow the attacker to elevate his/her privileges - after all, no one and nothing is perfect". I concur nothing is perfect, but a crash is a far thing from a security breach. Note, Multic's for years had the highest security of any commercial system, it was regarded as impossible to breach security, but a lot of people including Bill Gates discovered ways to crash it.
> I am afraid you just don't really know what you are talking about. Why do > you make this ridiculous statement about malicious attack at the time of > BSOD again and again???? After all, these two are totally independent > things > -I really don't know what makes you believe they may be somehow related.
> Now look at your following statement: > ///// > Do you know of any (just one is enough) example of Windows NT/2000/XP and > above working as designed that allows a user-mode application with only > normal privileges to crash the system? > /////
> This thread has been started off with such example, and this is what we > discuss here. How are we supposed to react to your question?????
> I am afraid you have posted your messages for the sole purpose of posting > them - they don't ask any questions that are relevant to this particular > discussion
> AFAIK there are about 1.5-2 testers for developer in MSFT ( as once Bill > Gates stand that MSFT's is huge test s/w house ) and they 're developing > code to test others ( OS ) code trying to find those types, you wrote > about > Arkady
> "anton bassov" <x...@yyy.com> wrote in message > news:0f459e0e7d6341e5bfd7e7c1cc51906f@ureader.com... >> Hi Carl
>> What I actually meant is new TYPES (!!!) of attack - this is what >> normally >> gets discovered accidentally, so that you just cannot foresee things like >> that. Once you know what to do, you can already systematically probe all >> places that you believe may be of interest, i.e. something what Mark >> Russinovich did. However, at this point, it is already possible to make >> provisions against this particular type of attack (because it is already >> known), so that the code that does not make such provisions can already >> qualify for being buggy
>> Regards
>> Anton Bassov
--