Question on taintcheck_patch()

[Jun Koi]

Hi,

Function taintcheck_patch() has the following check:

...
if (cpu_single_env->eip != 0xbf8a4bde &&
cpu_single_env->eip != 0xbf84a74f)
return 0;
...

I am wondering why we had that check, and how we found those addresses
(so we can also find these places for other Windows versions, like XP
SP3)?

Thanks,
Jun

[John]

I am focusing on the same question!

[Heng Yin]

This is a hackish way to fix the keystroke propagation in Windows. It
was briefly mentioned in Panorama paper. A "leave" instruction in
__xxxToUnicodeInternal was patched to fix the taint propagation.

Heng

[Stephen McCamant]

JK> Function taintcheck_patch() has the following check:
JK>
JK> ...
JK> if (cpu_single_env->eip != 0xbf8a4bde &&
JK>    cpu_single_env->eip != 0xbf84a74f)
JK>   return 0;
JK> ...
JK>
JK> I am wondering why we had that check, and how we found those
JK> addresses (so we can also find these places for other Windows
JK> versions, like XP SP3)?

>>>>> "Heng" == Heng Yin <yin...@gmail.com> writes:

Heng> This is a hackish way to fix the keystroke propagation in
Heng> Windows. It was briefly mentioned in Panorama paper. A "leave"
Heng> instruction in __xxxToUnicodeInternal was patched to fix the
Heng> taint propagation.

A few more notes on this topic:

* This has come up a few times before on the mailing list. You can
search for "taintcheck_patch" on the Google groups web page for some
more detailed previous discussions.

* A couple more addresses that we've found since the last release are
0xbf848d65 and 0xbf848d1c; one of them might work for your XP SP3.

* I believe that Heng is the one who has done this in the past, so he
can correct me if I'm wrong, but I believe we found these addresses
at least in the first place by examining tainted traces. Basically
you take a kernel-level trace with a tainted keystroke and see how
far it propagates. If the tainting never gets to your user-mode
processes, one of the places where propagation stops is an
under-tainting issue. Also I believe that function name information
for the Windows kernel is available, so now that we've found a
problem once, another possibility is to just use that to find the
address of the corresponding function in new kernel images.

Hope this helps,

-- Stephen