5 ms·

If I understand the exploit correctly, attackers are able to make a series of bad requests, record the error page display timing, and eventually figure out the

If I understand the exploit correctly, attackers are able to make a series of bad requests, record the error page display timing, and eventually figure out the machine key used for AES encryption. [EDIT: Even if my assumption of the nature of the exploit is wrong, that's not my point. My point is the questions below.] So, an attacker could alter the data of a cookie, thus impersonating a user or security level, and they could also alter the contents of ViewState. I don't use ViewState any more, having moved on to ASP.NET MVC, and I shudder to think what actually might get stored in there, but what is the route to alter ViewState and cause arbitrary commands to be executed on the server? I ask, because the article states this vulnerability allows an attacker to: "read data from files on the target server, such as web.config." Files like web.config are not allowed to be served up, out of the box, so does this SA assume that remote errors, which I believe will display a portion of the web.config, are enabled, or that this exploit can cause them to become enabled?

tptacek 16y ago
I'm bothered by the "web.config" thing too. As far as I know, Juliano and Thai haven't published yet, so we don't have full details, but I'm inclined to think this was a mistake on Microsoft's part.
- alecco 16y ago
  +ASP.NET > [Microsoft] did some good changes with Vista+, sure. But their code > base for most of their products is still a huge pile of crap, > security-wise. IIS, Exchange, Outlook, and even Windows itself. > Not all remote exec bugs are mitigated by the new OS features. http://news.ycombinator.com/item?id=1397222 http://news.ycombinator.com/item?id=1397222 Edit: Also at Ekoparty, Immunity presented their very cool looking ROPe compiler tools working against DEP/ASLR protections in Vista+.
  - tptacek 16y ago
    This comment is nonsensical; it says that one bug damns all of Microsoft as a "huge pile of crap", even though that one bug is basically shared by everyone who has implemented AES. Security researchers don't understand crypto. This is a hard fact that we all need to come to grips with. There are 100 people who can write clean-room ROP shellcode for every 1 who can explain CBC from memory. It's hard to blame Microsoft for that problem. The people who are good at crypto generally suck at software. The people who are good at software generally suck at crypto. (ROP shellcode, by the way? 2009-2010's new hotness. ASLR? From the early 2000's. Operating systems that reliably defeat ROP-style attacks? Zero.) Also, note the comment thread you're replying to. Instead of offering insight as to whether this flaw exposes configuration files, you've chosen to use it as a total non sequitor opportunity to pick a fight about Microsoft.
    - alecco 16y ago
      > This comment is nonsensical; it says that one bug damns all of > Microsoft as a "huge pile of crap", even though that one bug is > basically shared by everyone who has implemented AES. I'm not talking about bad use of crypto, I'm talking about: "the web.config thing" as an example of poor architecture legacy. Without all the issues in ASP.NET internal design, the Padding Oracle attack wouldn't be as serious as it is (IMHO.) > total non sequitor opportunity to pick a fight about Microsoft Again... I think Microsoft is doing an amazing job at security. But they still have a huge pile of legacy crap they need to address and sometimes, like ASP.NET "config thing", redesign. Your comments on this bug are very insightful and I do not want to pick a pointless fight over MS with you. I clearly failed to try to make you see my point of view (and perhaps not agree with but at least see it isn't just a bashing rant.)
      - euroclydon 16y ago
        Really? What is your favorite non-config-file-using web framework?
        alecco 16y ago
        Calm, I didn't mean no config file. But any file with sensitive information should be stored in a safe directory (not the root, for example) and with strict permissions. Also any sensitive data within that file should be protected if possible. This applies to any remotely accessed application, of course. Also, how does a process working with remote clients have full access to a sensible file like that? Aren't there ACL features or something like that that can block that access? (No sarcasm meant.)
      - tptacek 16y ago
        Sorry. I'm a bit defensive about this, given the crazy people running around saying "see, all you have to do is turn on customErrors to fix this flaw".
        alecco 16y ago
alecco 16y ago
From what I understood at the presentation, yes.
- euroclydon 16y ago
  Yes to what exactly?
  - alecco 16y ago
    >>> If I understand the exploit correctly, attackers are able to make >>> a series of bad requests, record the error page display timing, >>> and eventually figure out the machine key used for AES encryption. Yes. >>> I don't use ViewState any more, having moved on to ASP.NET MVC (From my inherently limited understanding) this is not just ViewState. That's just one of the multiple things vulnerable. I think they also mentioned ASP.NET MVC being vulnerable, too.

tptacek 16y ago

I'm bothered by the "web.config" thing too. As far as I know, Juliano and Thai haven't published yet, so we don't have full details, but I'm inclined to think this was a mistake on Microsoft's part.

alecco 16y ago
+ASP.NET > [Microsoft] did some good changes with Vista+, sure. But their code > base for most of their products is still a huge pile of crap, > security-wise. IIS, Exchange, Outlook, and even Windows itself. > Not all remote exec bugs are mitigated by the new OS features. http://news.ycombinator.com/item?id=1397222 http://news.ycombinator.com/item?id=1397222 Edit: Also at Ekoparty, Immunity presented their very cool looking ROPe compiler tools working against DEP/ASLR protections in Vista+.
- tptacek 16y ago
  This comment is nonsensical; it says that one bug damns all of Microsoft as a "huge pile of crap", even though that one bug is basically shared by everyone who has implemented AES. Security researchers don't understand crypto. This is a hard fact that we all need to come to grips with. There are 100 people who can write clean-room ROP shellcode for every 1 who can explain CBC from memory. It's hard to blame Microsoft for that problem. The people who are good at crypto generally suck at software. The people who are good at software generally suck at crypto. (ROP shellcode, by the way? 2009-2010's new hotness. ASLR? From the early 2000's. Operating systems that reliably defeat ROP-style attacks? Zero.) Also, note the comment thread you're replying to. Instead of offering insight as to whether this flaw exposes configuration files, you've chosen to use it as a total non sequitor opportunity to pick a fight about Microsoft.
  - alecco 16y ago
    > This comment is nonsensical; it says that one bug damns all of > Microsoft as a "huge pile of crap", even though that one bug is > basically shared by everyone who has implemented AES. I'm not talking about bad use of crypto, I'm talking about: "the web.config thing" as an example of poor architecture legacy. Without all the issues in ASP.NET internal design, the Padding Oracle attack wouldn't be as serious as it is (IMHO.) > total non sequitor opportunity to pick a fight about Microsoft Again... I think Microsoft is doing an amazing job at security. But they still have a huge pile of legacy crap they need to address and sometimes, like ASP.NET "config thing", redesign. Your comments on this bug are very insightful and I do not want to pick a pointless fight over MS with you. I clearly failed to try to make you see my point of view (and perhaps not agree with but at least see it isn't just a bashing rant.)
    - euroclydon 16y ago
      Really? What is your favorite non-config-file-using web framework?
      - alecco 16y ago
        Calm, I didn't mean no config file. But any file with sensitive information should be stored in a safe directory (not the root, for example) and with strict permissions. Also any sensitive data within that file should be protected if possible. This applies to any remotely accessed application, of course. Also, how does a process working with remote clients have full access to a sensible file like that? Aren't there ACL features or something like that that can block that access? (No sarcasm meant.)
    - tptacek 16y ago
      Sorry. I'm a bit defensive about this, given the crazy people running around saying "see, all you have to do is turn on customErrors to fix this flaw".
      - alecco 16y ago

alecco 16y ago

From what I understood at the presentation, yes.

euroclydon 16y ago
Yes to what exactly?
- alecco 16y ago
  >>> If I understand the exploit correctly, attackers are able to make >>> a series of bad requests, record the error page display timing, >>> and eventually figure out the machine key used for AES encryption. Yes. >>> I don't use ViewState any more, having moved on to ASP.NET MVC (From my inherently limited understanding) this is not just ViewState. That's just one of the multiple things vulnerable. I think they also mentioned ASP.NET MVC being vulnerable, too.