Slashdot Mirror

← Back to Stories (view on slashdot.org)

Microsoft To Release Emergency Fix For ASP.NET Bug

Posted by Soulskill on from the don't-make-us-do-stuff dept.

Trailrunner7 writes "Microsoft on Tuesday will release an emergency out-of-band patch for the ASP.NET padding oracle attack that was disclosed earlier this month. The patch will only be available on the company's Download Center for the time being, however. The company is taking the step of releasing an emergency fix for the bug because of the seriousness of the vulnerability — which potentially affects millions of Web applications — and the fact that there are attacks ongoing against it already. The patch will fix the flaw in all versions of the .NET framework. Although Microsoft issued guidance about workarounds to defend against attacks on the ASP.NET bug shortly after it was publicly disclosed, the researchers, Juliano Rizzo and Thai Duong, said that the workarounds did not fully protect users against their attack."

73 comments

  1. Thoid poist by Anonymous Coward · · Score: 0, Funny

    First I got foist, and now thoid. Where is everybody, out patching their servers?

  2. That Bogus Feeling by Tablizer · · Score: 0

    That link to the Microsoft Security Response Center looks bogus as hell. It doesn't have MS's usual (bland) colors and logo; and "Microsoft" is nowhere in the root of the URL. If I encountered that during the course of real work, I would probably just tilt my head and skip it.

    --
    Table-ized A.I.
    1. Re:That Bogus Feeling by Anonymous Coward · · Score: 2, Funny

      You obviously don't go there very often. TechNet has been a part of Microsoft for many years. It's where all the "IT Pros" go.

    2. Re:That Bogus Feeling by game+kid · · Score: 1

      "IT Pros"

      ie: ITT Tech flunkies.

      But "Flunkies Before Junkies" doesn't have the same appeal. :(

      --
      You can hold down the "B" button for continuous firing.
    3. Re:That Bogus Feeling by Anonymous Coward · · Score: 1, Insightful

      The only thing that is bogus is all the FOSS propaganda that you are spreading.

      Interesting side note: The captcha /. wants me to type out says "idiotic"

    4. Re:That Bogus Feeling by Anonymous Coward · · Score: 0

      I so wish I could Mod You Up. *thumbs up*

    5. Re:That Bogus Feeling by VGPowerlord · · Score: 1

      This is both a security advisory about the bug and a security bulletin about the upcoming patch on Microsoft's site. Does that make you happier?

      --
      GLaDOS for President 2016! "Well here we are again. It's always such a pleasure." -- GLaDOS, 2011
    6. Re:That Bogus Feeling by sharkey · · Score: 1

      Speaking as one MS IT Pro, I am eagerly waiting the latest planning and strategy guide. They are supposed to be covering Freecell Game #12269, which has proven rather difficult in my past attempts to agilely incentivize my proficiencies to maximize my spend and boost my TCO.

      --

      --
      "Outlook not so good." That magic 8-ball knows everything! I'll ask about Exchange Server next.
    7. Re:That Bogus Feeling by Tablizer · · Score: 1

      I only mentioned bland colors and logos. That's a tiny bash. If I *really* wanted to bash Microsoft, there'd be no mistaking.

      --
      Table-ized A.I.
    8. Re:That Bogus Feeling by Anonymous Coward · · Score: 0

      Happier than with the first reaction of MSFT's cheerleaders who shamelessly claimed everywhere that this was NOT a security issue.

      Now there's an 'out-of-band' patch ("coming soon") reading their clueless (but agressive against the researchers and the media which replyed the information) comments just look like the usual way of MICROSOFT to do business.

      Shame on you MICROSOFT. Such a "vulnerability" should have never existed.

  3. How serious is this really? by TheLink · · Score: 2, Insightful

    Microsoft is investigating a new public report of a vulnerability in ASP.NET. An attacker who exploited this vulnerability could view data, such as the View State, which was encrypted by the target server, or read data from files on the target server, such as web.config.

    Why would decrypting a cookie allow you to read data from files on the target server?

    What if you just use cookies for storing session ids?

    Using cookies to store lots of secrets seems like a stupid idea to me. Server-side secrets belong server-side.

    Furthermore what if the user wants to use more than one browser window? If you are too reliant on cookies to store state it means the webapp would get confused in that scenario.

    --
    1. Re:How serious is this really? by D+Ninja · · Score: 4, Informative

      First off...it's not a "decrypted cookie" - it's not that at all. The entire bug allows an attacker to download server-side information (such as web.config) which can potentially contain (and often does) information that should not be public.

      Scott Guthrie wrote up a very detailed post on the vulnerability. It's fairly easy to exploit (there are videos available showing the ease in which it can be exploited), so it should be of concern to administrators and individuals writing websites/web applications running on ASP.NET.

    2. Re:How serious is this really? by DiegoBravo · · Score: 1

      I really don't understand why some random client can access such information, even after breaking any encryption mechanism.

      From http://blogs.technet.com/b/srd/archive/2010/09/17/understanding-the-asp-net-vulnerability.aspx

      "For example, if the ASP.Net application stores sensitive information, such as passwords or database connection strings, in the ViewState object this data could be compromised. The ViewState object is encrypted and sent to the client in a hidden form variable, so it is a possible target of this attack.

      If the ASP.Net application is using ASP.Net 3.5 SP1 or above, the attacker could use this encryption vulnerability to request the contents of an arbitrary file within the ASP.Net application. The public disclosure demonstrated using this technique to retrieve the contents of web.config. Any file in the ASP.Net application which the worker process has access to will be returned to the attacker. "

    3. Re:How serious is this really? by ls671 · · Score: 0, Troll

      But, but...

      Being an equal opportunity fan and enjoying playing the devil advocate, I went to search for an instance where a remote attacker could read web.xml to no avail.

      web.xml is used by multiple application server implementations offering the most prevalent alternative to ASP.NET.

      So did anybody ever heard of a security hole that allowed a remote attacker to read web.xml ?

      --
      Everything I write is lies, read between the lines.
    4. Re:How serious is this really? by Anonymous Coward · · Score: 0

      ^^^^ Some java guy is willing to put his penis on the butcher block betting that Java doesn't have any obscure cryptographic flaws.

      Not that he needs it anyway, he's probably Indian. ;)

    5. Re:How serious is this really? by corsec67 · · Score: 1

      If the ASP.Net application is using ASP.Net 3.5 SP1 or above, the attacker could use this encryption vulnerability to request the contents of an arbitrary file within the ASP.Net application.

      Breaking the encryption is one thing, that is just !!!! GAH !!!

      Does that mean that a client that is authorized with a key to decrypt the encryption has access to "an arbitrary file within the ASP.Net application"?

      This would then seem like 2 very different issues: the oracle helping break the encryption, and the "request a file" issue.

      --
      If I have nothing to hide, don't search me
    6. Re:How serious is this really? by ls671 · · Score: 1

      Not really ;-)

      I remember freaking out when servlets and jsps came out and I realized that web.xml was by default right under the root directory of the site, right under WEB-INF. I thought back then that some implementation would screw up and make it readable.

      The natural approach I was used to back then was to put httpd.conf in a directory that only root could read while apache would run under a different uid.

      Still, never mind my fears from 10 years ago but I have never heard about a remote attacker managing to read web.xml although I would bet some implementation must have had that security hole.

      So, short story, I was really looking for a case where a remote attacker managed to read web.xml although my quick search didn't reveal anything ;-)

      --
      Everything I write is lies, read between the lines.
    7. Re:How serious is this really? by spongman · · Score: 2, Informative

      the padding oracle vulnerability allows you to do two things:
      1) decrypt cyphertet that has been encrypted using the site's machineKey
      2) encrypt arbitrary plaintext as if you knew the machineKey

      it doesn't give you the machineKey, but you can encrypt/decrypt as if you had it.

      There's another vulnerability that allows you to download arbitrary files (even 'protected' ones) if you are able to encode plaintext with the site's machineKey. ScriptResource.axd is used by asp.net to compress/bundle scripts, and it takes a parameter that is encoded using the machineKey. The assumption is that the machineKey is secret, so it bypasses the regular pipeline that includes the checks for protected files. However, even though the attacker doesn't know the machine key, he is able to use the oracle to correctly encode the parameter to ScriptResource.axd, download web.config and learn further secrets.

      Further, if the site encodes authentication tickets into the cookies in a predictable manner, the attacker can use the oracle to forge other valid authentication tickets. This is the attack that's shown in the video.

    8. Re:How serious is this really? by SplashMyBandit · · Score: 1

      I'm sure you're aware Java EE technologies are pretty secure in general. Sun were much better than Microsoft at security - even if Sun were much worse at business.

    9. Re:How serious is this really? by TheLink · · Score: 1

      Does that really mean if anyone knows the secret they can get any file the webserver can access?

      If that's true about ASP.NET in general, then ASP.NET's _design_ is broken.

      In contrast, with sane designs, I could even tell you the db password that the webapps use to access data/state from the db, but if you're outside, you can't touch anything (unless you're one of those elite hackers who have dozens of "zero days" stored up for a rainy day).

      You could even have the ssh login credentials, but you'd have to get inside in the first place to use them.

      So this is a design bug, not an implementation bug?

      --
    10. Re:How serious is this really? by benjymouse · · Score: 1

      You are wrong. This vulnerability is actually an artifact of the underlying encryption algorithm, and as such other products are also vulnerable, e.g. JSF (for which attacks were demonstrated before the ASP.NET one) and Ruby-on-Rails. It allows you to retrieve the full key. And the key is symmetrix, meaning that you can both decrypt and encrypt.

      The attacker can gradually learn the exact machine key by manipulating something he knows to be encrypted. By padding the encrypted text from the end, and watching to see whether the server decryption fails or he hits something which *can* actually decrypt (but which may causes the app to fail), he can learn something about the key. Presumably this is because he knows that the last part of the key is used to encrypt the last part of the text.

      Anything encrypted will do. Even the timing of the failure may offer the attacker valuable information, e.g. failure to decrypt results in faster fails than the application trying to run with something which actually decrypted without error only to fail a little later.

      This is not specific to ASP.NET. But ASP.NET happens to use the machine key to encrypt authentication tickets. If you learn the machine key then you can fake any identity.

      As this is a standard algorithm, expect the ASP.NET fix to be a sanity check (hash/signature) on the entire ciphertext so that it can reject it up front before even attempting to decrypt. Ruby-on-Rails has a similar method where you must explicitly request verify and decrypt instead of just decrypt.

      --
      Reading slashdot one-liner: (irm http://rss.slashdot.org/Slashdot/slashdot).rdf.item | fl title,desc*
    11. Re:How serious is this really? by @madeus · · Score: 1

      Hmm....Solaris was pretty remote exploit tastic :-) I'd say even worse (shudder) than Windows NT, until you shut off all the hideous exploitable RPC services which were on by default!

    12. Re:How serious is this really? by Anonymous Coward · · Score: 0

      I'm sure you're aware Java EE technologies are pretty secure in general. Sun were much better than Microsoft at security - even if Sun were much worse at business.

      And how many flaws have been found in the java runtime? Lots.

    13. Re:How serious is this really? by spongman · · Score: 2, Informative

      You are wrong. This vulnerability is actually an artifact of the underlying encryption algorithm, and as such other products are also vulnerable, e.g. JSF (for which attacks were demonstrated before the ASP.NET one) and Ruby-on-Rails.

      the vulnerability isn't in the encryption algorithm, it's in the implementation of the CBC operation of the block cypher.

      It allows you to retrieve the full key. And the key is symmetrix[sic], meaning that you can both decrypt and encrypt.

      No, the oracle doesn't give you the key. The key and the encryption algorithm are irrelevant. The oracle allows you to retrieve the IV for a given cypher block, but most importantly it allows you to encrypt/decrypt without the key.

      The attacker can gradually learn the exact machine key by manipulating something he knows to be encrypted. By padding the encrypted text from the end, and watching to see whether the server decryption fails or he hits something which *can* actually decrypt (but which may causes the app to fail), he can learn something about the key. Presumably this is because he knows that the last part of the key is used to encrypt the last part of the text. Anything encrypted will do. Even the timing of the failure may offer the attacker valuable information, e.g. failure to decrypt results in faster fails than the application trying to run with something which actually decrypted without error only to fail a little later.

      The above is mostly correct, but again, the attacker doesn't learn the key, just the IV required to generate correct padding.

      This is not specific to ASP.NET. But ASP.NET happens to use the machine key to encrypt authentication tickets.

      The built-in authentication methods do encrypt the ticket with the machine key. However...

      If you learn the machine key then you can fake any identity.

      This is not necessarily true. The identity placed in the ticket is generated by the application. If the developer chooses a predictable form of ticket, then, yes, you can generate tickets for other users. However, a developer can easily use a non-predictable ticket format to thwart this part of the attack.

      As this is a standard algorithm, expect the ASP.NET fix to be a sanity check (hash/signature) on the entire ciphertext so that it can reject it up front before even attempting to decrypt. Ruby-on-Rails has a similar method where you must explicitly request verify and decrypt instead of just decrypt.

      They could fix this just by hiding the padding exception, and maybe adding a little random delay. It'll be interesting to see what changes they made, in 45 minutes or so...

    14. Re:How serious is this really? by SplashMyBandit · · Score: 1

      Agreed. I once was called into to clean up a 1 million dollar Nuclear Magnetic Resonance system (on IRIX) where the software developers had use RPC that ran as root but had no password. Needless to say it was taken over remotely.

    15. Re:How serious is this really? by ls671 · · Score: 1

      I should have replied to parent but I try to avoid conflicts ;-)

      So anyways; you were basically right in your GGP post. Never mind the RPC topic.

      I have learned around 1990 (from people who had learned it before that date ) that RPC access should be filtered at the firewall + host level.

      I am still using RPC because it is just to handy for some tasks and other people are doing it too.

      Oh, and by the way, as I speak today; same goes for SMB shares and services (ports 137, 139, 445) even in a Microsoft only implementation environment. I made some money out of it (fixing things, of course).

      So, I believe that it is fair to say that the two most prevalent alternatives are at par with regards to this topic (RPC vs SMB).

      --
      Everything I write is lies, read between the lines.
  4. Scott Guthrie's post with details by Anonymous Coward · · Score: 3, Informative

    Better link for details and workarounds:

    http://weblogs.asp.net/scottgu/archive/2010/09/18/important-asp-net-security-vulnerability.aspx

  5. "padding oracle"? by 93+Escort+Wagon · · Score: 2, Funny

    So does this involve an Oracle database somehow - in which case "Oracle" should have been capitalized - or are we talking about a real, honest-to-goodness oracle? Did the attack originate in Greece?

    --
    #DeleteChrome
    1. Re:"padding oracle"? by Anonymous Coward · · Score: 0

      Indeed, here are the steps for taking advantage of this flaw:

      1. travel to Greece
      2. look up one of the oracles mentioned in TFA who were discovered to know the secret behind this flaw
      3. submit a web.config file from your chosen target's site
      4. wait...Thread.Sleep(9000)...zzz...
      5. oracle will provide you with decrypted web.config
      6. use sensitive data to ruin company
      7. rinse and repeat

    2. Re:"padding oracle"? by Anonymous Coward · · Score: 1, Informative

      Oracle in the sense of an oracle telling you information.
      The delay in the response among other things reveals the key.

    3. Re:"padding oracle"? by jamesh · · Score: 1

      So does this involve an Oracle database somehow - in which case "Oracle" should have been capitalized - or are we talking about a real, honest-to-goodness oracle?

      For a moment I thought we were talking about _the_ Oracle, although that also should have been capitalized. I think it's unwise to draw any conclusions from spelling or grammatical forms that you might see on the internet though. Even more unwise if the source is slashdot :)

      For instance, if you saw the phrase "I had to help my uncle Jack off a horse" on slashdot, it would be probably still be a story about equine masturbation.

    4. Re:"padding oracle"? by Anonymous Coward · · Score: 0

      Why would someone capitalize the "J" in that phrase if they were referring to masturbation?

    5. Re:"padding oracle"? by ardeez · · Score: 1, Funny

      Did the attack originate in Greece?

      Yeah, it was written in Dephi

      --
      don't be a spelling loser
    6. Re:"padding oracle"? by L4t3r4lu5 · · Score: 1

      No, it was developed by Atreyu in Fantasia. Falkor helped.

      --
      Finally had enough. Come see us over at https://soylentnews.org/
  6. That is correct. by apparently · · Score: 1
    Everybody is busy patching their servers with the patch that isn't going to be released until tomorrow.

    First I got foist, and now thoid. Where is everybody, out patching their servers?

    1. Re:That is correct. by Anonymous Coward · · Score: 0

      It's already tomorrow here in 'Strayla. Give me the URL to your web and I'll break in and patch it for you.

  7. Ah, that's the answer by thePowerOfGrayskull · · Score: 1

    Release it as an optional download in the download center. I'm sure that the vast majority of Windows admins (especially shared web hosts, but ) will get that installed right away! While I understand why they have to do it this way (forcing an update on your enterprise clients is generally Very Bad for some very valid reasons), I would think that they (and those who could be impacted) would be better served if they said "This will be available for 3 days on the download center for you to download and test; then it will become mandatory in order for your enterprise to receive continued support.

    1. Re:Ah, that's the answer by Anpheus · · Score: 1

      It will be released as the highest level of critical update on Windows Update for home and small business users and for WSUS for small to large enterprise users that control patch distribution in-house. The former will be able to choose to ignore the update (but if they ever called support, the question "Are you up to date?" could come up) and the latter can even choose to require the update by a deadline in their business. If some department neglects to schedule and manually install at an appropriate time, the server will follow orders from on high and install that update, department head be damned.

      Actually I'm not sure if the update will require a restart, but it probably will.

    2. Re:Ah, that's the answer by thePowerOfGrayskull · · Score: 1

      Damn. I hate it when I post without knowing what I'm talking about.

  8. A quick explanation by rabtech · · Score: 4, Informative

    First, the ViewState is encrypted so figuring out the key allows you to inject your own data into the ViewState. The worse an app's code, the worse the exploit on this because some apps even store their "IsAdmin" flag in the ViewState and other such nonsense, so this lets you impersonate any user you like. DotNetNuke is one example of a crappy system. Worse, it allows you to upload ZIP files of themes and whatnot, so you can use this to impersonate the superuser, upload some hacks, then try to execute them. Depending on what account ASP.Net runs under and whether you are fully patched, this can lead to escalation to admin and owning the box. If you have followed all the other in-depth security practices (and for coders don't store any sensitive info in the ViewState) then this isn't nearly as big of a deal.

    The big hole is that starting with 3.5 SP1 (and also in 4.0) the WebResource.axd handler takes an encrypted filename as its parameter, so you can encrypt say "web.config" and get it to happily pipe web.config to you... or any other file. It completely bypasses the normal restricted file handler. In previous releases this was not the case, the stuff it would let you download was much more limited. Granted, there are facilities to encrypt connection strings/etc in web.config, but a lot of people are lazy and just deploy with plaintext passwords and whatnot. Again, following defense in-depth practices greatly restricts the scope of any potential attack.

    IMHO the WebResource.axd issue is inexcusable. There is no legitimate reason for allowing the new behavior.

    --
    Natural != (nontoxic || beneficial)
    1. Re:A quick explanation by ls671 · · Score: 0

      WTF ?

      Is this serious ? I thought rule 1 of using cookies was to only put meaningless data into one. I am still having a hard time to believe this is occurring out of the box in an enterprise platform like ASP.NET.

      --
      Everything I write is lies, read between the lines.
    2. Re:A quick explanation by Anonymous Coward · · Score: 5, Informative

      Seriously? This is the second reply to this story that seems to think that it's about cookies.

      Please listen carefully: this has NOTHING to do with cookies!

      As the GP post and Scott Guthrie's post linked elsewhere (so helpfully) explain, this affects two encrypted elements in use by most (if not all) ASP.NET apps: the ViewState (not a cookie, rather a hidden, encrypted field for storing state across postbacks) and encrypted web.config files which tend to store sensitive connection info (among other things) that needs to be protected from attackers. The flaw allows attackers to decrypt these storage mechanisms and so get at (potentially) sensitive data, depending on how the app was coded.

    3. Re:A quick explanation by ls671 · · Score: 2, Interesting

      > not a cookie, rather a hidden, encrypted field for storing state across postbacks

      Thanks a lot for the clarification, it seriously helps me understand the problem better and I really mean it.

      Now I will re-phrase my post:

      WTF ?

      Is this serious ? I thought rule 1 of using hidden form fields was to only put meaningless (OK: or already submitted data by the user) data into one. I am still having a hard time to believe this is occurring out of the box in an enterprise platform like ASP.NET.

      A hidden form field in more or less the request scoped version of a cookie, never ever store your guts into one, no matter how well it is encrypted ! ;-)

      --
      Everything I write is lies, read between the lines.
    4. Re:A quick explanation by Anonymous Coward · · Score: 0

      So what exactly is the difference between storing an encrypted data (eg authentication tokens) in a cookie, and storing it in ViewState?

    5. Re:A quick explanation by Anonymous Coward · · Score: 1, Interesting

      Practically nothing with regards to what kind of data shouldn't be stored in either, but it pays to be precise when talking about a problem that needs fixing to ensure you're not "fixing" the wrong code.

    6. Re:A quick explanation by Yaur · · Score: 1

      It isn't WebResource.axd... its ScriptResource.axd that has the file download vulnerability.
      The purposes of this (mis)feature is to allow the ScriptManager to prevent clients from using stale versions of a script from cache. The problem is that ScriptResource.axd doesn't sanity check what kind of files it is serving up. Furthermore, since this behavior is out in the field it is impossible for MS to know if anyone is using it, so "fixing" it might break some unknown customers' sites in a way that is non trivial to fix. This will obviously piss people off.

      I wrote a module that uses a user configurable white list of file types that are permitted for download through the ScriptManager which is more rational behavior IMO. Of course, depending on what MS pushes tomorrow this may or may not still be relevant.

    7. Re:A quick explanation by Anonymous Coward · · Score: 1, Interesting

      Hey, you won't find me disagreeing on your point about not storing sensitive things in cookies or ViewState and, as the OP pointed out, with proper security practices in place, this is less of an issue than having your encrypted web.config file exposed.

      As for your disbelief, I honestly can't imagine having the foresight to protect against an attack that involves:

      This allows an attacker to send cipher text to the web server and learn if it was decrypted properly by examining which error code was returned by the web server. By making many such requests (and watching what errors are returned) the attacker can learn enough to successfully decrypt the rest of the cipher text.

      and the TechNet site even mentions that an attacker can use the timing of the response to deduce the type of error (devious!) even if you use the proposed customErrors workaround.

      People make mistakes and MS is being quick about releasing the fix. Can't realistically ask for much more than that. Also, a comment above seems to indicate that this isn't restricted to ASP.NET, but can affect other frameworks that use similar mechanisms.

    8. Re:A quick explanation by ls671 · · Score: 1

      > but can affect other frameworks that use similar mechanisms.

      Yep, JSF included apparently ;-)

      Some people tend to forget rule 1...

      I mean it must be just too easy to store a meaningless token in a cookie or hidden form field and to map it to something meaningful on the server. Why adopt the easy way when we can do more complicated stuff some would say ?

      --
      Everything I write is lies, read between the lines.
    9. Re:A quick explanation by mr+exploiter · · Score: 1

      Making up rules after the fact when an exploit is found doesn't make you wise, it makes you look like a smart ass. Please point up to where somebody that matters said that posting encrypted data was not good enough BEFORE this was know. Encrypted data seems pretty meaningless to me.

    10. Re:A quick explanation by Anonymous Coward · · Score: 0

      Well, the guy who reviewed my code for our administrative backend system objected to this design in part of our system (encrypted data as auth token sent to another server via a web client) over a year ago on the basis that it violated best practice.

      And in our system there is no padding oracle, and it's available only to a a few dozen IP addresses of machines physically located in our offices.

      We switched to sending an arbitrary UUID to the client and associating the authorization with the UUID and a timestamp in a database shared between the two servers. That meant a hypothetical attacker needs an active MitM attack on an HTTPS connection rather than just a way to encrypt his own authorization messages. If they can break into our SSL traffic we're game over anyway.

      But then we're also one of those companies who gets audits done and then fixes what they found, whereas ASP.NET is some cowboy operation by people who still think Visual BASIC is a pretty neat idea.

    11. Re:A quick explanation by ls671 · · Score: 1

      I learned rule 1 15 years ago. It seems like you are the smart ass ;-)

      --
      Everything I write is lies, read between the lines.
    12. Re:A quick explanation by Anonymous Coward · · Score: 1, Informative

      First, the ViewState is encrypted so figuring out the key allows you to inject your own data into the ViewState.

      The hidden ViewState field is not encrypted. It's base-64 encoded, which is a big difference. You can view any .NET page's ViewState field contents by simply running it through a base 64 decoder. THAT'S why you're not supposed to store sensitive shit in it...it was never encrypted in the first place, and any jackass willing to read the documentation to .NET can explore it freely.

      "This combined, saved state is then serialized into a base-64 encoded string. In stage 7, when the page's Web Form is rendered, the view state is persisted in the page as a hidden form field." - http://msdn.microsoft.com/en-us/library/ms972976.aspx

    13. Re:A quick explanation by david_thornley · · Score: 1

      Since modern ciphers appear to be completely unbreakable when used properly, people have been turning to "side-channel" attacks, such as observing the timing or where the CPU heats up or such things to break into the processing of the cipher and getting clues about the key. These are becoming increasingly common and important.

      There are reasonable people out there who trust AES just fine when all encryption and decryption is done off-line, but don't if a possible attacker can get timing information or some other sort of observation.

      --
      "When you have eliminated the unacceptable, whatever is left, however improbable, must be the truthiness" - Holmes
    14. Re:A quick explanation by Shados · · Score: 1

      Its not encrypted (by default: it -CAN- be encrypted using features out of the box), but there is a hash to prevent tempering of the viewstate.

      However you have to be careful, by default this is still vulnerable to a replay attack, so its still better not to push your luck with it.

    15. Re:A quick explanation by ls671 · · Score: 1

      > completely unbreakable

      By design, they are meant to be broken so why take a risk that brings you nothing when an easy alternative is available ?

      There is many stories about encryption being broken and attackers taking advantage of it.

      Only rely on encryption when you have no other choices. See poster below about best practices.

      --
      Everything I write is lies, read between the lines.
  9. hidden form element is no different than a cookie by Anonymous Coward · · Score: 0

    one is in the header, the other is in content, but its all equally visible to the user, there is no difference in how each should be protected, none, EXACT SAME PRINCIPLES APPLY

  10. Re:hidden form element is no different than a cook by Anpheus · · Score: 1

    Agreed, and as he said, if you apply all the right practices, your connection strings will be encrypted, your app won't do something stupid, your IIS worker will be a limited rights user, etc, etc.

  11. Re:Flashbacks by shutdown+-p+now · · Score: 0, Flamebait

    The pwnage is not restricted to ASP.NET, it's just the angle on which Slashdot focuses (unsurprisingly, considering the target audience). Same attack can be used against JSF - indeed, that's what the original presentation did, in painstaking detail - you've read it, right? The authors also claim that Rails applications can be similarly vulnerable, depending on whether one of the stock modules is used.

    Another reason why the stories mainly center around ASP.NET is that it's vulnerable out of the box (though so is JSF), and, more importantly, of all vulnerable frameworks, it's the single most common one, and also the one for which the admins are most likely to be clueless.

  12. oracle attack ??? by MadMaverick9 · · Score: 1

    must be larry who's behind all this ...

    1. Re:oracle attack ??? by Anonymous Coward · · Score: 0

      Nope, it's Agent Smith.

  13. So... where`s the fix? by __aavqan3009 · · Score: 1

    am I just overlooking it?

    1. Re:So... where`s the fix? by Anonymous Coward · · Score: 0

      You can find it here:

      http://www.microsoft.com/technet/security/bulletin/ms10-070.mspx

  14. The person you replied to? He's obviously... by Anonymous Coward · · Score: 0

    A malware maker (per his reply (which you replied to) and telling others here to "skip it"). Thank goodness someone (you) put up something contrary to his utter bullshit, with actual links to Microsoft's other pages to verify this as a legit security patch to .NET and the OS itself. You never know what others MIGHT believe, so thank goodness someone set that idiot straight. Good job on your part.

  15. Good job shutdown -p now by Anonymous Coward · · Score: 0

    "The pwnage is not restricted to ASP.NET, it's just the angle on which Slashdot focuses (unsurprisingly, considering the target audience). Same attack can be used against JSF - indeed, that's what the original presentation did, in painstaking detail - you've read it, right? The authors also claim that Rails applications can be similarly vulnerable, depending on whether one of the stock modules is used.

    Another reason why the stories mainly center around ASP.NET is that it's vulnerable out of the box (though so is JSF), and, more importantly, of all vulnerable frameworks, it's the single most common one, and also the one for which the admins are most likely to be clueless." - by shutdown -p now (807394) on Tuesday September 28, @01:05AM (#33719638)

    Per my subject-line, good job man: Have to give you that much here.

    I mean, this site, being so "pro-*NIX" only makes sense - they're a "sister site" to Linux world iirc (same publications online owned by same party iirc (but, do correct me if I am wrong here, it's been a while since I checked on this much, thanks)) so, it's always in their "best interest" to attack MS whenever possible.

    I have no problem with it though, as long as the news is legit though, & not b.s., such as this post here was I replied to as well started by Tablizer (who strikes me as a malware maker who is currently taking advantage of this security vulnerability based on his reply, see for yourself on that account, & judge for yourself as to my conclusion):

    http://it.slashdot.org/comments.pl?sid=1801306&threshold=-1&commentsort=0&mode=thread&pid=33721382

    They never cease to amaze. I am a user of Linux myself, I actually have grown to LIKE KDE's "latest/greatest" on Linux's "latest/greatest" from KUbuntu (10.04.1/64-bit) but, I do NOT like when "FUD" and utter disinforming/misinforming b.s. is spewed around here. DISCLAIMER: Yes, I am also a Windows 7 64-bit MS fan too!

    (However, bottom-line & MOST HILARIOUS PART HERE? Look how you were "modded down" for merely telling it how it is around here... unbelievable!)

    APK