5 ms·

Can anyone provide any more solid details? This article seems to be a lot of hyperbole ("totally destroys") with little fact. The error message provides a sma

Can anyone provide any more solid details? This article seems to be a lot of hyperbole ("totally destroys") with little fact. The error message provides a small tidbit of information about how ASP.NET decrypts messages. With enough of these error messages it is possible to decrypt the message in its entirety. What message? The cookie itself?

daeken 16y ago
As far as I can tell, this seems to allow you to decrypt the data within cookies. However, what would be stored within these cookies aside from a session ID? Some insight into what's actually stored in the cookie would be good, as this seems very overblown.
- pixelbath 16y ago
  Honestly, if you're storing sensitive user information, or site access information in your cookies, then you deserve the resulting exploits. I agree, unless this attack completely crashes the .Net stack to allow privilege escalation or similar, it's complete hyperbole.
  - ars 16y ago
    So the users login token is not "sensitive user information"?
  - nopal 16y ago
    I'm inclined to disagree. Encrypted cookies should be secure, provided the underlying encryption techniques are solid. There are cases where having sensitive information in a cookie makes sense. In a web farm, for example. A session store that serves a farm of web servers is harder to set up and maintain than having clients send information back in a cookie. If it's properly encrypted, then this shouldn't be a problem. (Signed cookies are also good for this scenario, if it's okay for the data to be seen by others) Am I wrong? EDIT: Here's a good thread on how to ensure data on client cookies hasn't been tampered with: http://news.ycombinator.com/item?id=1687826 http://news.ycombinator.com/item?id=1687826
    - dionysiac 16y ago
      Storing something like a username in client-side data and then trusting its accuracy is effectively delegating your authentication outside you circle of control. Saying that encryption will make this magically secure is like saying encryption makes for effective DRM - eventually it will be compromised and you will have a systemic problem. Storing, say, a username and a password hash in your encrypted cookie is at least as secure as direct authentication at each page load; even if they break your encryption they still have to know the admin's password. Start with the assumption that the locks you use for security will fail, and ask "how will this break?" If we take the encryption out of the picture, do we trust the client to log in as root (or similar) with just a username and no password? The lock in question (as I understand it) is failing for an unrelated (information disclosure) reason. The design decision to lean so hard on the lock is what makes this such an issue.
      - DennisP 16y ago
        It's not like DRM. Effective DRM is impossible because the client has to have the decryption key. All you can do is try to obscure it.
  - tptacek 16y ago
    This notion of encrypted cookies or tokens being an inherently bad mechanism to store information securely is a red herring. The fact is that these platforms --- .NET, JSF, Rails, Django included --- provide functionality that stores encrypted information client-side. When that functionality is broken, it's a platform-level security flaw. Whether you're right or your wrong (and I would tend to agree that storing sensitive information clientside --- or doing anything else that involves encryption --- isn't worth the risk), this isn't a productive point to make. These designs exist, and can be secure, but contain flaws that must be corrected, lest many tens of applications be susceptible to devastating attacks.
- mrkurt 16y ago
  It would allow you to encrypt new cookies. The default authenticated cookies for ASP.NET forms auth is a username. If you can encrypt your own username/id values into your cookie, you can effectively make ASP.NET think you're logged in as whoever you want.
sp332 16y ago
It's a "padding oracle" attack, see tptacek's comment here: http://news.ycombinator.com/item?id=1687547 http://news.ycombinator.com/item?id=1687547
thinkzig 16y ago
This is the whitepaper: http://usenix.org/events/woot10/tech/full_papers/Rizzo.pdf http://usenix.org/events/woot10/tech/full_papers/Rizzo.pdf
- tptacek 16y ago
  I believe that's an older white paper.
pragmatic 16y ago
Discussion on Reddit: http://www.reddit.com/r/programming/comments/df72k/quite_serious_security_hole_in_aspnet_discovered/ http://www.reddit.com/r/programming/comments/df72k/quite_ser...
- tptacek 16y ago
  Someone want to sum this up for me? I'm genuinely afraid to click through that link.
  - SamReidHughes 16y ago
    It's a more hostile and verbose version of the thread here.
    - tptacek 16y ago
      Guess what? Reddit outdid us on this one. james_hart in particular, but also a series of smaller clarifying comments. Look at this one: http://www.reddit.com/r/programming/comments/df72k/quite_serious_security_hole_in_aspnet_discovered/c0zsnws http://www.reddit.com/r/programming/comments/df72k/quite_ser... The HN thread consists basically of knee-jerking about "those waskly sekuwity wesearchers" and blatantly overtly false statements from people who had no business giving guidance about a flaw they knew literally nothing about.
      - SamReidHughes 16y ago
        Welp, the first comment was deleted. That completely changes the apparent tone.

daeken 16y ago

As far as I can tell, this seems to allow you to decrypt the data within cookies. However, what would be stored within these cookies aside from a session ID? Some insight into what's actually stored in the cookie would be good, as this seems very overblown.

pixelbath 16y ago
Honestly, if you're storing sensitive user information, or site access information in your cookies, then you deserve the resulting exploits. I agree, unless this attack completely crashes the .Net stack to allow privilege escalation or similar, it's complete hyperbole.
- ars 16y ago
  So the users login token is not "sensitive user information"?
- nopal 16y ago
  I'm inclined to disagree. Encrypted cookies should be secure, provided the underlying encryption techniques are solid. There are cases where having sensitive information in a cookie makes sense. In a web farm, for example. A session store that serves a farm of web servers is harder to set up and maintain than having clients send information back in a cookie. If it's properly encrypted, then this shouldn't be a problem. (Signed cookies are also good for this scenario, if it's okay for the data to be seen by others) Am I wrong? EDIT: Here's a good thread on how to ensure data on client cookies hasn't been tampered with: http://news.ycombinator.com/item?id=1687826 http://news.ycombinator.com/item?id=1687826
  - dionysiac 16y ago
    Storing something like a username in client-side data and then trusting its accuracy is effectively delegating your authentication outside you circle of control. Saying that encryption will make this magically secure is like saying encryption makes for effective DRM - eventually it will be compromised and you will have a systemic problem. Storing, say, a username and a password hash in your encrypted cookie is at least as secure as direct authentication at each page load; even if they break your encryption they still have to know the admin's password. Start with the assumption that the locks you use for security will fail, and ask "how will this break?" If we take the encryption out of the picture, do we trust the client to log in as root (or similar) with just a username and no password? The lock in question (as I understand it) is failing for an unrelated (information disclosure) reason. The design decision to lean so hard on the lock is what makes this such an issue.
    - DennisP 16y ago
      It's not like DRM. Effective DRM is impossible because the client has to have the decryption key. All you can do is try to obscure it.
- tptacek 16y ago
  This notion of encrypted cookies or tokens being an inherently bad mechanism to store information securely is a red herring. The fact is that these platforms --- .NET, JSF, Rails, Django included --- provide functionality that stores encrypted information client-side. When that functionality is broken, it's a platform-level security flaw. Whether you're right or your wrong (and I would tend to agree that storing sensitive information clientside --- or doing anything else that involves encryption --- isn't worth the risk), this isn't a productive point to make. These designs exist, and can be secure, but contain flaws that must be corrected, lest many tens of applications be susceptible to devastating attacks.
mrkurt 16y ago
It would allow you to encrypt new cookies. The default authenticated cookies for ASP.NET forms auth is a username. If you can encrypt your own username/id values into your cookie, you can effectively make ASP.NET think you're logged in as whoever you want.

sp332 16y ago

It's a "padding oracle" attack, see tptacek's comment here: http://news.ycombinator.com/item?id=1687547 http://news.ycombinator.com/item?id=1687547

thinkzig 16y ago

This is the whitepaper: http://usenix.org/events/woot10/tech/full_papers/Rizzo.pdf http://usenix.org/events/woot10/tech/full_papers/Rizzo.pdf

tptacek 16y ago
I believe that's an older white paper.

pragmatic 16y ago

Discussion on Reddit: http://www.reddit.com/r/programming/comments/df72k/quite_serious_security_hole_in_aspnet_discovered/ http://www.reddit.com/r/programming/comments/df72k/quite_ser...

tptacek 16y ago
Someone want to sum this up for me? I'm genuinely afraid to click through that link.
- SamReidHughes 16y ago
  It's a more hostile and verbose version of the thread here.
  - tptacek 16y ago
    Guess what? Reddit outdid us on this one. james_hart in particular, but also a series of smaller clarifying comments. Look at this one: http://www.reddit.com/r/programming/comments/df72k/quite_serious_security_hole_in_aspnet_discovered/c0zsnws http://www.reddit.com/r/programming/comments/df72k/quite_ser... The HN thread consists basically of knee-jerking about "those waskly sekuwity wesearchers" and blatantly overtly false statements from people who had no business giving guidance about a flaw they knew literally nothing about.
    - SamReidHughes 16y ago
      Welp, the first comment was deleted. That completely changes the apparent tone.