Security issues with automatic URL dereference

| Comments (2) | SYSSEC
Martin Rex points to this whitepaper about a claimed security flaw in RFC 3280 (the RFC for X.509/PKIX certificates). The issue is that certificates can contain a variety of URLs, including:
  • Intermediate certificates (for the signer of this cert).
  • Pointers to the certificate policy statement
  • Pointers to where you can get a CRL
  • Pointers to an OCSP server

When your client goes to validate the certificate, it may (automatically) try to retrieve what's on the other end of the URL. Arguably, this is bad:

However, elegant does not usually mean secure. The problem in this case is that until the certificate chain is verified, the user sending the certificate is usually untrusted. This means that the specified URI has to be treated as potentially evil input from an unauthenticated user. This simple fact is missing from the "Security Considerations" section of the RFC and thus implementors have gotten it wrong.

When implemented naively, this means that an unauthenticated user can embed arbitrary URIs within a certificate and can thus force the verifier to send out arbitrary HTTP requests on its behalf -- for example to networks formerly unreachable to an attacker. The response itself is not forwarded to the attacker, so he is limited to blind attacks. A specific case of this can be used to gain information about the verifier -- for example whether he has opened a certain email or office document. As more than one URI can be embedded in the certificate, it would also theoretically be possible to gain information on internal networks using timing information. For this, one would create a certificate with one URI controlled by the attacker, one URI internal to the attacked, one URI controlled by the attacker and measure the timing distance between the two accesses to the attacker-controlled URIs. In practical experience, this is still theoretical, though.

This certainly is technically true, but it's unclear how serious this issue is. After all, if your mail client is willing to read HTML mail (and many are) and if it automatically retrieves inline images (many do), then it's pretty easy for the sender to verify that you read a given message, and potentially mount the timing attacks these researchers describe (though it's an open question whether this would work.) There are actually a number of protocols that have automatic URL dereference built in.

There's actually something more interesting, though tricky to exploit (and harder to deal with) here. The white paper talks about probing internal servers, but depending on what services are running there and what ports they're running on, there's some possibility that the client (presumably behind the firewall) could talk to the internal server and do more than detect it. Theoretically, it might be able to give it instructions that it would follow. How well this actually works depends a lot on what the internal service you're talking to is. The attacker doesn't get much control of the message it sends to the server, it just gets to embed the URL in some HTTP GET request. Obviously, since the client is talking HTTP, it would be most convenient if you were talking to an HTTP server, since you'd be protocol compliant. In theory, HTTP GETs are not supposed to have side effects on the server, but of course that happens all the time.

If the server isn't HTTP, then you have to get pretty lucky. You need to be able to encode a meaningful protocol request in the URI and the server needs to be resilient enough to nonconformant traffic that it's willing to ignore the bogus HTTP request wrapper and process whatever request is embedded in the URI. This obviously isn't superconvenient for the attacker, who would like a much finer degree of control of the protocol messages, like you'd get with a client-side program (hence the browser same origin policy).

2 Comments

the complications of avoiding cross-site request
forgery are daunting. i am not a security expert,
but it seems to me the onus is on the server to
``validate the transaction'', as Schneier puts it

but, yeah, as far as the client's behavior--if
the client ascribes some value to the use of the
certificate and wants to derive more by checking
its references, then that's a decision the client
makes (however inadvisedly). i'd hope that the
handling of network transactions for purposes of
certificate verification would be done with as
wary an eye as any other aspect of the handling
of the certificate

Eric, you messed up the href tag on same source policy link. It is 'hef' in your page. Makes for an odd user-experience: Looks like a link, smells like a link, doesn't click anywhere.

Leave a comment