Six Step IE Remote Compromise Cache Attack

Tyler Larson wrote:

> In fact, I'd go as far as to say that in dealing with any open-source
> software at all, development of a POC exploit is never necessary.

In some cases that's true. But if it's a remotely exploitable hole that
doesn't require prior authentication of the attacker and it affects
widespread software, I'd rather like to see a proof-of-concept exploit.

Why? Even if the admin in charge has applied a patch (or a
configuration change), there's a non-zero probability that something
goes wrong: the service is not restarted, the wrong version of the
package has been installed, the file system contains another copy of the
software which is the one that is actually running, the patch lacks a
hunk and is ineffective, the system compiler optimized away the new
security check, and so on.

If you look at the recent DCOM scanners, you'll notice that they work
without PoC code. Microsoft implemented some unrelated changes, and the
difference in behavior is externally observable. If you have got the
source code, you usually apply minimal patches which often don't even
change the version number (distributions such as Debian and SuSE have a
policy to backport just the isolated security fixes). That's why remote
probing almost always requires an exploit of some kind. Not a complete
exploit, with an extensive collection of offsets and shellcode for
various platforms, but some proof of concept, so that we are able to
check if we are in doubt.

> It's generally easier (and always more productive) to develop the fix
> than the POC anyway.

Sometimes this is true. A deterministic proof-of-concept exploit for
the recent ircd bug was quite hard to construct, fixing it was much
easier (I had applied a fix even before I fully understand the problem
and upstream agreed that there was in fact a problem 8-).

> And if a vendor patch exists, POC code won't help anybody. Why?
> Because the existance of a security patch already adequately
> demonstrates the existance of a potential threat.

I agree that exploit code is less helpful for threat assessment. After
all, you don't know if the exploit is representative for all methods of
attack, and if it demonstrates the maximum possible impact.

However, as outlined above, there are other uses for exploit code. Of
course, it doesn't really apply to passive attacks on clients such as
web browsers (but I presume that the discussion has slipped a bit 8-).

Paul Schmehl said:

> We need a paradigm shift in programming from "allow all but the
> known bad" to "disallow all but the known good", don't we?

We need a little bit more than that, because our understanding of
"what's bad" increases with time, and that frequently reduces the set
of "what's good."

For example, I recently audited a web application that inherently
disallowed all but known good inputs, by design. Some of you know how
much of a rare pleasure it can be to audit well-designed software ;-)
It kept close track of "immutable" fields and would exit whenever any
tampering was detected. It did a pretty good job of using regular
expressions to restrict input.

Unfortunately, it was subject to a CRLF injection vulnerability, which
was not publicly known at the time the application had been developed.
And the CRLF injection attack normally would not have worked thanks to
the app's design, except the web application had a "feature" (perhaps
accidental) in which a customized control file could define new fields
that should have been labeled immutable, but were not.

As a different example, consider directory traversal issues in which
".." sequences are separated by illegal characters that are filtered
out only *after* the ".." check is performed. The process goes like:

1) Software checks for ".." sequences and generates an error if any
are found

2) Software cleanses and canonicalizes the input

Such software could be subject to directory traversal via a ".|."
sequence that isn't found in step 1, but the "|" gets removed in step
2; or maybe a "%2e%2e" URL encoding would work.

While this may be an example of an "allow all but known bad" approach,
there are also lessons to be learned about designing the software so
that security-sensitive operations are performed in the proper order.
In addition, there's a need to know and explicitly model which
vulnerabilities a piece of data may be exposed to at different points
in time. It's not just "known good," it's "known good under a
specific context at a specific time."

- Steve

> But wrongly rejecting good input has no security implications.
> But wrongly accepting bad input has.

Are you sure about that? It's arguable that it's the outcome of the
action that is more important than the content or value of the action
itself (i.e. By action or admission of action allow an offence to be
committed).

If I have backdoored a system, and I can have the system reject good
input (i.e. the sysadmin issuing a command to remove the backdoor), then
the system has continued to remain insecure as a result of rejecting
good input.

That may be a contrived example, but this is a topic that bears being
pedantic ;) so if a principle isn't true in all cases it isn't true at all.


--

For good, return good. For evil, return justice.

"Goetz Babin-Ebell" <babin-ebell@trustcenter.de> said:

>> We need a little bit more than that, because our understanding of
>> "what's bad" increases with time, and that frequently reduces the set
>> of "what's good."
>
>Yes.
>But wrongly rejecting good input has no security implications.

Actually, I'm starting to see evidence that it can, if you think of
"susceptibility to denial of service" as a security issue.

Specifically, the software not only has to recognize the bad input, it
has to generate an error condition, then properly respond to it.

A few types of vulnerabilities have been reported due to bad error
handling on security-relevant conditions:

- An application detects an input that's too long and returns a NULL
pointer, which then causes a crash when the pointer is dereferenced.

In fact, I suspect that some of the so-called "buffer overflows"
that get reported these days are really null pointer problems.
Researchers are encouraged to consider this in their diagnoses.

- An application detects a bad input and reports an error, but it
doesn't "exit" out of the code, and goes right on processing the bad
input.

>I don't think we should primarily look for vulnerabilities,
>but we all should spend more time on the definition of allowed input
>and reject all that is not in these limits.

I agree that more attention should be paid to identifying *exactly*
what "allowed input" means. For example, directory traversal issues
could probably be entirely eliminated as a class if the software's
design restricted file names to be alphanumeric with a single file
extension. The programmer may cry "but that limits flexibility in
file naming!" but it's in that flexibility where danger lies.

On the other hand, alphanumeric tests can be insufficient if you also
want to avoid MS-DOS device name problems...

- Steve

> -----Original Message-----
> From: Goetz Babin-Ebell [mailto:babin-ebell@trustcenter.de]
> Sent: Monday, November 10, 2003 11:25 AM
>
> But wrongly rejecting good input has no security implications.
> But wrongly accepting bad input has.

Coding to satisfy only security implications, in a vacuum separated from the
rest of the world, all the security bugs in the world can be fixed simply by
removing all the features.

Wrongly rejecting good input has a very strong implication - your program
fails to do what it is tasked with. You can call that a security
implication, in that security's task is not just to prevent access by the
unwashed, but also to allow, provide and facilitate access to those that are
approved.

If all we are doing is trying to prevent unauthorised access, then all we
have to do is turn off, unplug, and shred, our computers. There - security
made easy.

Alun.
~~~~
--
Texas Imperial Software | Find us at http://www.wftpd.com or email
1602 Harvest Moon Place | alun@texis.com.
Cedar Park TX 78613-1419 | WFTPD, WFTPD Pro are Windows FTP servers.
Fax/Voice +1(512)258-9858 | Try our NEW client software, WFTPD Explorer.

--------------ms000204080601000904010104
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Hello Alun,

Alun Jones wrote:
>>-----Original Message-----
>>From: Goetz Babin-Ebell [mailto:babin-ebell@trustcenter.de]
>>Sent: Monday, November 10, 2003 11:25 AM
>>
>>But wrongly rejecting good input has no security implications.
>>But wrongly accepting bad input has.
>
> Coding to satisfy only security implications, in a vacuum separated from the
> rest of the world, all the security bugs in the world can be fixed simply by
> removing all the features.

That is not what I have said:
You define a field of accepted inputs (your white list)
All inputs, that do not match the white list,
is rejected with an error.

Now you have to study the errors with the supplied input.
If there is some input that should be accepted,
you have to adapt your white list.
(After testing that this inpuut doesn't barf your program...)

> Wrongly rejecting good input has a very strong implication - your program
> fails to do what it is tasked with.

Only for those inputs you are not sure
that it really does what it should do.
And that is good.
An error message is always better than an wrong result.

> You can call that a security
> implication, in that security's task is not just to prevent access by the
> unwashed, but also to allow, provide and facilitate access to those that are
> approved.

Your program has a function.
If gets some inputs, does some operations and generates some outputs.

There are 3 differend kinds of inputs:
1. inputs you are sure it will generate correct output
2. inputs you are sure it will generate unwanted output
3. inputs you don't know what output it will will generate

You want only to generate error messages for inputs of kind 2.
I want to generate error messages for inputs of the kinds 2 & 3.

Lets have an example:
A program that gets a number and calculates the next number.

For some inputs it will generate correct outputs.
For other inputs you are either not sure or you know that
it will generate some wrong output.

The used data type is unsigned char.

The 1st version of the input test function is:

BOOL CheckInput(const char*in)
{
if (!in)
return FALSE;
if (in[0] >= '0' && in[0] <= '9' && !in[1])
return TRUE;
return FALSE;
}

This is OK until the first customer tries
the number 10 and gets an error message.

Reading (and testing) the code, we find:
there is no problem with 2 digit numbers.

So the 2nd version of the input test function is:

BOOL CheckInput(const char*in)
{
if (!in)
return FALSE;
if (in[0] >= '0' && in[0] <= '9' && !in[1])
return TRUE;
if (in[0] >= '0' && in[0] <= '9' &&
in[1] >= '0' && in[1] <= '9' && !in[2])
return TRUE;
return FALSE;
}

This is OK until the first customer tries
the number 100 and gets an error message.

Reading (and testing) the code, we find:
there is a problem with numbers bigger than 255.

So the 3rd version of the input test function is:

BOOL CheckInput(const char*in)
{
if (!in)
return FALSE;
if (in[0] >= '0' && in[0] <= '9' && !in[1])
return TRUE;
if (in[0] >= '0' && in[0] <= '9' &&
in[1] >= '0' && in[1] <= '9' && !in[2])
return TRUE;
if (in[0] >= '0' && in[0] <= '9' &&
in[1] >= '0' && in[1] <= '9' &&
in[2] >= '0' && in[2] <= '1' && !in[3])
return TRUE;
if (in[0] >= '0' && in[0] <= '9' &&
in[1] >= '0' && in[1] <= '9' &&
in[2] == '2' && in[1] >= '0' && && in[1] <= '4'
&& !in[3])
return TRUE;
if (in[0] >= '0' && in[0] <= '9' &&
in[1] >= '0' && in[1] <= '9' &&
in[2] == '2' && in[1] == '5' && in[0] >= '0' && in[0] <= '5'
&& !in[3])
return TRUE;
return FALSE;
}

Now we have found the real limits of the program.
But the importand fact is:
For all input the program ever accepted,
it calculated the correct output.


> If all we are doing is trying to prevent unauthorised access, then all we
> have to do is turn off, unplug, and shred, our computers. There - security
> made easy.

I did never say we should dump our computers.
I did say our programs should only accept
input we are sure they process correctly.


Bye

Goetz

--
Goetz Babin-Ebell, TC TrustCenter AG, http://www.trustcenter.de
Sonninstr. 24-28, 20097 Hamburg, Germany
Tel.: +49-(0)40 80 80 26 -0, Fax: +49-(0)40 80 80 26 -126

--------------ms000204080601000904010104
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCS qGSIb3DQEHAQAAoIIIkDCC
BEQwggOtoAMCAQICDwCQHgAAAAJOQu0jEgf3pTANBgkqhkiG9w 0BAQUFADCBvDELMAkGA1UE
BhMCREUxEDAOBgNVBAgTB0hhbWJ1cmcxEDAOBgNVBAcTB0hhbW J1cmcxOjA4BgNVBAoTMVRD
IFRydXN0Q2VudGVyIGZvciBTZWN1cml0eSBpbiBEYXRhIE5ldH dvcmtzIEdtYkgxIjAgBgNV
BAsTGVRDIFRydXN0Q2VudGVyIENsYXNzIDMgQ0ExKTAnBgkqhk iG9w0BCQEWGmNlcnRpZmlj
YXRlQHRydXN0Y2VudGVyLmRlMB4XDTAzMDIxMDE0NDI1MFoXDT A0MDIxMDE0NDI1MFowgaox
CzAJBgNVBAYTAkRFMRAwDgYDVQQIEwdIYW1idXJnMRAwDgYDVQ QHEwdIYW1idXJnMRowGAYD
VQQKExFUQyBUcnVzdENlbnRlciBBRzEUMBIGA1UECxMLRW50d2 lja2x1bmcxGjAYBgNVBAMT
EUdvZXR6IEJhYmluLUViZWxsMSkwJwYJKoZIhvcNAQkBFhpiYW Jpbi1lYmVsbEB0cnVzdGNl
bnRlci5kZTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCgg EBALB6adN6EChrpAbT5KV1
ceRRIDAoGnz2gsBoFI2BwJLS+RpuIZfdJOepm4crg3X6LXrMKw SF/lshFeHrVPtLzabgLGyF
SujsJP0z3u7f4XNYCGHl4UbyPkYboIP9GC/DRtsknO1YfJUy/4yKBG4VjJ4AP6vZTEQey6jm
xelsK2ek4vwRfUjs/z9UcZmtj4ipiHP6IqFyydDTLarn1jWHUu2zFnJzryZ6mXdOUPi hCOFG
D+c1KFksZ1VscgDpKygTQcIg/VItmbeFkhOj9IkboOyiVKvvfhujlxmdm9ACt22MjMrB0RAb
9TR1DgXlyofwykKAK+GM8Cu8jcKaJjvfhaMCAwEAAaOB0zCB0D AMBgNVHRMBAf8EAjAAMA4G
A1UdDwEB/wQEAwIF4DA+BglghkgBhvhCAQgEMRYvaHR0cDovL3d3dy50cnV zdGNlbnRlci5k
ZS9ndWlkZWxpbmVzL2luZGV4Lmh0bWwwEQYJYIZIAYb4QgEBBA QDAgWgMF0GCWCGSAGG+EIB
AwRQFk5odHRwczovL3d3dy50cnVzdGNlbnRlci5kZS9jZ2ktYm luL2NoZWNrLXJldi5jZ2kv
OTAxRTAwMDAwMDAyNEU0MkVEMjMxMjA3RjdBNT8wDQYJKoZIhv cNAQEFBQADgYEAObOwuCFG
0HmVvCm8llpJ3qsBqtZgFyUT0wuz8JG6CZjHn5lwvOg+8m8huK rE5oGEQIo9EwLcFLDNVsxB
CiwjX2juU3JQl2Hs2smUyHkOqg+W0COetRp+PcDAk4hk0Mth5A 3bDy3FrzyhbjpYjAZTvnsY
9+QYmJm5cGWBJK9I7kIwggREMIIDraADAgECAg8AkB4AAAACTk LtIxIH96UwDQYJKoZIhvcN
AQEFBQAwgbwxCzAJBgNVBAYTAkRFMRAwDgYDVQQIEwdIYW1idX JnMRAwDgYDVQQHEwdIYW1i
dXJnMTowOAYDVQQKEzFUQyBUcnVzdENlbnRlciBmb3IgU2VjdX JpdHkgaW4gRGF0YSBOZXR3
b3JrcyBHbWJIMSIwIAYDVQQLExlUQyBUcnVzdENlbnRlciBDbG FzcyAzIENBMSkwJwYJKoZI
hvcNAQkBFhpjZXJ0aWZpY2F0ZUB0cnVzdGNlbnRlci5kZTAeFw 0wMzAyMTAxNDQyNTBaFw0w
NDAyMTAxNDQyNTBaMIGqMQswCQYDVQQGEwJERTEQMA4GA1UECB MHSGFtYnVyZzEQMA4GA1UE
BxMHSGFtYnVyZzEaMBgGA1UEChMRVEMgVHJ1c3RDZW50ZXIgQU cxFDASBgNVBAsTC0VudHdp
Y2tsdW5nMRowGAYDVQQDExFHb2V0eiBCYWJpbi1FYmVsbDEpMC cGCSqGSIb3DQEJARYaYmFi
aW4tZWJlbGxAdHJ1c3RjZW50ZXIuZGUwggEiMA0GCSqGSIb3DQ EBAQUAA4IBDwAwggEKAoIB
AQCwemnTehAoa6QG0+SldXHkUSAwKBp89oLAaBSNgcCS0vkabi GX3STnqZuHK4N1+i16zCsE
hf5bIRXh61T7S82m4CxshUro7CT9M97u3+FzWAhh5eFG8j5GG6 CD/Rgvw0bbJJztWHyVMv+M
igRuFYyeAD+r2UxEHsuo5sXpbCtnpOL8EX1I7P8/VHGZrY+IqYhz+iKhcsnQ0y2q59Y1h1Lt
sxZyc68mepl3TlD4oQjhRg/nNShZLGdVbHIA6SsoE0HCIP1SLZm3hZITo/SJG6DsolSr734b
o5cZnZvQArdtjIzKwdEQG/U0dQ4F5cqH8MpCgCvhjPArvI3CmiY734WjAgMBAAGjgdMwgdAw
DAYDVR0TAQH/BAIwADAOBgNVHQ8BAf8EBAMCBeAwPgYJYIZIAYb4QgEIBDEWL2 h0dHA6Ly93
d3cudHJ1c3RjZW50ZXIuZGUvZ3VpZGVsaW5lcy9pbmRleC5odG 1sMBEGCWCGSAGG+EIBAQQE
AwIFoDBdBglghkgBhvhCAQMEUBZOaHR0cHM6Ly93d3cudHJ1c3 RjZW50ZXIuZGUvY2dpLWJp
bi9jaGVjay1yZXYuY2dpLzkwMUUwMDAwMDAwMjRFNDJFRDIzMT IwN0Y3QTU/MA0GCSqGSIb3
DQEBBQUAA4GBADmzsLghRtB5lbwpvJZaSd6rAarWYBclE9MLs/CRugmYx5+ZcLzoPvJvIbiq
xOaBhECKPRMC3BSwzVbMQQosI19o7lNyUJdh7NrJlMh5DqoPlt AjnrUafj3AwJOIZNDLYeQN
2w8txa88oW46WIwGU757GPfkGJiZuXBlgSSvSO5CMYIEdzCCBH MCAQEwgdAwgbwxCzAJBgNV
BAYTAkRFMRAwDgYDVQQIEwdIYW1idXJnMRAwDgYDVQQHEwdIYW 1idXJnMTowOAYDVQQKEzFU
QyBUcnVzdENlbnRlciBmb3IgU2VjdXJpdHkgaW4gRGF0YSBOZX R3b3JrcyBHbWJIMSIwIAYD
VQQLExlUQyBUcnVzdENlbnRlciBDbGFzcyAzIENBMSkwJwYJKo ZIhvcNAQkBFhpjZXJ0aWZp
Y2F0ZUB0cnVzdGNlbnRlci5kZQIPAJAeAAAAAk5C7SMSB/elMAkGBSsOAwIaBQCgggJ7MBgG
CSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ 8XDTAzMTExMTIwMjU0N1ow
IwYJKoZIhvcNAQkEMRYEFPVQThw0iPyeeiZIPfdvXNIRY01NMF IGCSqGSIb3DQEJDzFFMEMw
CgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQ MCAgFAMAcGBSsOAwIHMA0G
CCqGSIb3DQMCAgEoMIHhBgkrBgEEAYI3EAQxgdMwgdAwgbwxCz AJBgNVBAYTAkRFMRAwDgYD
VQQIEwdIYW1idXJnMRAwDgYDVQQHEwdIYW1idXJnMTowOAYDVQ QKEzFUQyBUcnVzdENlbnRl
ciBmb3IgU2VjdXJpdHkgaW4gRGF0YSBOZXR3b3JrcyBHbWJIMS IwIAYDVQQLExlUQyBUcnVz
dENlbnRlciBDbGFzcyAzIENBMSkwJwYJKoZIhvcNAQkBFhpjZX J0aWZpY2F0ZUB0cnVzdGNl
bnRlci5kZQIPAJAeAAAAAk5C7SMSB/elMIHjBgsqhkiG9w0BCRACCzGB06CB0DCBvDELMAkG
A1UEBhMCREUxEDAOBgNVBAgTB0hhbWJ1cmcxEDAOBgNVBAcTB0 hhbWJ1cmcxOjA4BgNVBAoT
MVRDIFRydXN0Q2VudGVyIGZvciBTZWN1cml0eSBpbiBEYXRhIE 5ldHdvcmtzIEdtYkgxIjAg
BgNVBAsTGVRDIFRydXN0Q2VudGVyIENsYXNzIDMgQ0ExKTAnBg kqhkiG9w0BCQEWGmNlcnRp
ZmljYXRlQHRydXN0Y2VudGVyLmRlAg8AkB4AAAACTkLtIxIH96 UwDQYJKoZIhvcNAQEBBQAE
ggEAbWcYYx2avYsbqs+alli+CLPC9G41rWMI1M/YK+l2LY9pu9CFkZTIRTVRQ1DEecc7tpdi
hXMEaSD4NR6OxrIDiI5kYsIjYIaRY9jifjRHTDl870SCZG+OLf br/hZKGcz4tw2XGQTb0WDq
UDJXAqY3IFJ0hy0J7cwcCT53KKic2bBU1IJs59xtSISz/wwUyYFN9vZpLEGnTBc24x04g2gL
uCIQQ2vxCE2B9DTTPY5fZ2WYNBGSWa/9w1li/BfvGXvZAWW2dXheadZ6/EtLak4Wp6QN7l5I
+hbxUkSlFhb+Fi/k+2Fp/00IwC7q2kGLo8LYxeKQmgy7JddWPJqHl8AiFwAAAAAAAA==
--------------ms000204080601000904010104--