Onderwerp: Followup: vuln in WinBlox monitor for winnt

The good fellows that moderate this list pointed out to me that my
last post regarding Liu Die Yu's winblox utility was a little thin on
details and might get percieved as a bit of a pissing competition. =
That's
precisely what I was trying to avoid by being vague, so let's get this
clear=3D85

WinBlox is using the App_InitDLLs registry key to install a wrapper
around the CreateFileW function in _every_ process system wide. This =
isn't a
new trick, it's a simple version of the way many user-mode rootkits on =
NT
work. And I know first hand that several readers on this list have =
thought
about the same things Liu is doing in the past.

The problem with these system wide hooking tricks is that they are
very powerful, but also very risky. When you change the behaviour of a
critical windows function like CreateFileW you run the risk of a bug in =
your
code introducing a new vuln into every single process on the system. So =
it's
of paramount importance that the wrapper code be bullet-proof. Taking a =
look
at Liu's code, it's anything but bulletproof, the execution path =3D =
following
from every call to CreateFileW is full of nasty programming practices =
that
can create vulns.

Here's a full back-of-the-napkin analysis of the dangerous _sprintf
call I mentioned in the previous post (you'll find the disassembly =
listing
there), it's hypothetical and just off the top of my head, but the point =
is
the potential implications of buggy code when your trying to make this =
sort
of patch, not the strength of this specific analysis:

> Afaict, he's calling _sprintf to print data into a 2k stack based=20
> buffer, called Text in the disassembly (ebp - 0x800). Look at the=20
> format string:
>=20
> "CreateFile:%s > %s =3D=3D> %s --> %s"
>=20
> So in order to trigger a buffer overflow in any process on a system=20
> where Liu's runtime patch is running, you need to get the length of=20
> this string, with substitutions, to exceed 2k in any process locally=20
> or remotely. Let's look at some of his sample output:
>=20
> 2004/03/26 @ 09:33:29.224 # createfile:c:\program=20
> files\icqlite\icqlite.exe
> > "c:\program files\icqlite\icqlite.exe" -minimize =3D=3D>
> generic_read|generic_write -->=20
> \\?\root#system#0000#{3e227e76-690d-11d2-8161-0000f8775bf1}\{cd171de3-
> 69e5-1
> 1d2-b56d-0000f8754380}&{9b365890-165f-11d0-a195-0020afd156e4}
>=20
> 2004/03/26 @ 09:33:29.144 # createfile:c:\windows\explorer.exe >=20
> c:\windows\explorer.exe =3D=3D> unknown_access_code:00000000 -->=20
> c:\windows\system32\wdmaud.drv
>=20
> 2004/03/26 @ 09:27:45.590 #=20
> createfile:\??\c:\windows\system32\winlogon.exe
> > winlogon.exe =3D=3D> generic_read --> c:\windows\system32\kbdus.dll
>=20
> The arguments in order are the name of the current process, the=20
> current processes command line, a textual representation of the flags=20
> to CreateFileW, and finally the file being opened. Getting this to=20
> exceed 2k doesn't sound too tough to me; the only length check is on=20
> the file name. Since the last substitution is the name of the file=20
> which is user supplied in many cases (like IIS for example...), it's=20
> very easy to stick a shellcode in there.
>=20
> So what this thing is going to do is stick a potential buffer=20
> overflow into every process in the system that can potentially be=20
> triggered whenever a file is opened. Not so very good. If I'm correct=20
> finding cases where it can be exploited is a bit tedious, since each=20
> process that will be running Liu's patch is different, but that's not=20
> the point. You don't want to 'fix' windows by injecting a potential=20
> buffer-overflow into it whenever a file is opened. And there are=20
> several other potentially dangerous _sprintfs that follow throughout=20
> his new CreateFileW function.
>=20
> Regardless of whether or not I've made a mistake in my analysis,=20
> there's plenty of evidence that this thing is not quite ready for=20
> prime-time, which is a shame, because it's a good idea.
>=20

That's it. No pissing competition. Liu's onto something very good
here, but as anyone who installs MS patches will tell ya, you've got to =
see
the full implications of a fix before you choose to apply it. Until this
thing gets rewritten properly, and follows even the most basic =
principals of
secure coding, it'll cause more problems than it fixes, in my opinion.

I firmly believe that these sorts of tricks have tonnes of potential
and are going to become even more common in the future of the "so called
security community" tho'

Cheers,
~ol


---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.605 / Virus Database: 385 - Release Date: 01/03/2004
=20

=20

> -----Original Message-----
> From: Oliver Lavery [mailtoliver.lavery@sympatico.ca]=20
> Sent: Tuesday, March 30, 2004 1:11 PM
> To: bugtraq@securityfocus.com
> Subject: Followup: vuln in WinBlox monitor for winnt

<snip>
>=20
> That's it. No pissing competition. Liu's onto something=20
> very good
> here, but as anyone who installs MS patches will tell ya,=20
> you've got to see
> the full implications of a fix before you choose to apply it.=20
> Until this
> thing gets rewritten properly, and follows even the most=20
> basic principals of
> secure coding, it'll cause more problems than it fixes, in my opinion.
>=20
> I firmly believe that these sorts of tricks have tonnes=20
> of potential
> and are going to become even more common in the future of the=20
> "so called
> security community" tho'

<snip>

Honestly, most [95%+-] "beta" or "alpha" programs do "cause more
problems then they fix".=20

Liu Die Yu is relatively new at development, but he is relatively new at
finding bugs -- and he has succeeded substantially at that. I do not
doubt that he will succeed substantially at this.=20

And, all of this is yet another great reason to immediately put code
opensource at an excellent hosting spot like sourceforge... even from
the design phase, but especially from the alpha release stage.

Then you have the ability to have others to help out... and you have
such neat, modern resources such as bug databases and submission forms.=20

I do not think Liu Die Yu will take half a year or more to fix his bugs.