Microsoft Issuing Unusual Out-of-Band Security Update 156
wiredmikey writes "In a rare move, Microsoft is breaking its normal procedures and will issue an emergency out-of-band security update on Thursday to address a hash collision attack vulnerability that came into the spotlight yesterday, and affects various Web platforms industry-wide. The vulnerability is not specific to Microsoft technologies and has been discovered to impact PHP 5, Java, .NET, and Google's v8, while PHP 4, Ruby, and Python are somewhat vulnerable. Microsoft plans to release the bulletin on December 29, 2011, at 10:00 AM Pacific Time, and said it would addresses security vulnerabilities in all supported releases of Microsoft Windows. 'The impact of this vulnerability is similar to other Denial of Service attacks that have been released in the past, such as the Slowloris DoS or the HTTP POST DoS,' said security expert Chris Eng. 'Unlike traditional DoS attacks, they could be conducted with very small amounts of bandwidth. This hash table multi-collision bug shares that property.'"
Microsoft updates before Google and Oracle? (Score:5, Interesting)
Re: (Score:1)
"before others" ?
A workaround so that Apache Tomcat (a Java webserver) ain't affected is already out. Oracle may be slower on that one but Java webservers are getting patched as we're writing this.
So, well, good job for Apache!
Re: (Score:2)
In fact Oracle claims that a fix in Java is not needed and they will fix Glassfish. I believe MS will do the same and will fix the ASP.NET request/response pipeline and not the core HashTable implementation.
Re: (Score:2)
According to MS11-100 (the advisory) they changed the Framework, not ASP.NET.
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
If you use Flash to handle the uploads it'd be trivial to split it into multiple POSTs and recombine on the server-side afterward.
Re: (Score:2)
Re: (Score:2)
I like to think HTML5 will be there pretty soon.
Re: (Score:2)
"Limit maximum POST size: Limiting the maximum POST request size can reduce the number of possible predictable collisions, thus reducing the impact of an attack."
This is disingenuous at best. It reduces the number of possible collisions, but increases the number of likely collisions, by reducing the size of the input set.
This is easy to see by reducing the problem (reductio ad absurdum): imagine the likelihood of collisions given 1000 posts, limited to 1000 characters each. Now imagine the likelihood of a collision given 1000 posts, limited to 3 characters each. The number of collisions due to cryptographic weakness might become ridiculously small, but th
Re: (Score:2)
Well, for a start, the server platform does not necessarily have any awareness of what the application running on it has already sent - basically it has no idea that a "file upload form" has been requested because it is essentially content-agnostic. It doesn't care what gets sent to and from it, that's the application's job. And besides, the server has to actually receive the content before it can ascertain that the maximum post size has been reached - unless it forcibly aborts the upload but then it has
Re:Microsoft updates before Google and Oracle? (Score:5, Insightful)
Do you realize the irony of calling someone else a shill, given the content of your message?
It wasn't that long ago that Slashdot conversations were both rational and coherently written. Thanks for ruining both of those things for everyone.
Now, now... (Score:4, Interesting)
Re: (Score:2)
Re:Microsoft updates before Google and Oracle? (Score:5, Funny)
Re: (Score:2)
I've been here a long time, and I can't say that I ever remember conversations being rational - although they are occasionally coherent.
quoted for truth
Re: (Score:2)
It wasn't that long ago that Slashdot conversations were both rational and coherently written.
Honestly, I think that may be a sign you're growing up.
Re: (Score:3)
It wasn't that long ago that Slashdot conversations were both rational and coherently written.
Honestly, I think that may be a sign you're growing up.
Or sobering up.
Re: (Score:1)
It's precisely because it affects different platforms that MS is rolling out the update before others.
Uh, what are you trying to say here? I thought trolls had to make some sense in order to be effective.
Maybe times are a-changing.
Re: (Score:2)
I love how ACs are almost always abrasive assholes who can't form a coherent argument.
It's like, classic reverse trolling. So antiquated that it has looped around into some weird sincerity.
Anyways, this is good on MS which is particularly a desktop software company, whereas web-oriented companies like Google should be expected to have acted on this sooner since this affects their entire market.
Re: (Score:2)
Re: (Score:2)
Hence why I said almost. I was not suggesting removing the feature or anything.
Re: (Score:2)
...It's precisely because it affects different platforms that MS is rolling out the update before others. It is good for their damaged PR. Other than that they don't really care about having a secure platform.
Apart from the foul language, you hit the nail right on the head.
Re:Microsoft updates before Google and Oracle? (Score:4, Insightful)
No it wouldn't, there's PLENTY of obvious troll accounts on Slashdot. To be honest, it's all part of the parcel of Slashdot. The first post is generally a waste of time. The second post is usually also a waste of time, often someone trying to GET the first post. The real discussions happen further down, where the trolls can't be bothered to read.
Despite all the idiots, I still find slashdot to be a worthy place for discussion with plenty of insightful and knowledgeable people around - you just have to look for it.
Re: (Score:2)
The first post is generally a waste of time. The second post is usually also a waste of time, often someone trying to GET the first post.
Do you have any idea how weird that looks to a pedant like myself?
<form method="post"> => POST the first post
Re: (Score:2)
But nice, anyways. Next time I'll have the opportunity, I'll shoot for frist get!
Re: (Score:2)
Patents could have saved us! (Score:3, Funny)
See, everyone here complains that patents are always causing trouble, forcing each developer to do something a little differently to avoid infringing on another patent. If the techniques used for parsing the hash tables had been patented, forcing each server developer to come up with their own unique implementation that didn't mimic the techniques of the others, then this whole situation might only have impacted one or two server technologies. Now, all of these different server technologies using similar implementations are all affected by this single type of attack. With all of the diversity that patents enforce, they could have prevented a single attack like this from affecting so many implementations at once!
[/sarcasm]
Re: (Score:2)
Re:Patents could have saved us! (Score:5, Informative)
Re: (Score:3)
Priorities (Score:5, Insightful)
Re:Priorities (Score:5, Informative)
That the DDoS exists is yesterday's news (nevermind that it didn't make the Slashdot front page.) The point of this post is that Microsoft is issuing an out-of-band update. A security-aware and in-touch admin should have already learned of the n.runs advisory [nruns.com] yesterday. If they were really on top of things, they may have been aware of the potential danger as far back as 2003.
Re: (Score:3, Interesting)
You've gotta love how /. reports this in an unbiased way :)
BTW it is not DDoS but just DoS (no distributed coordinated attack needed just a single request). Also it is not a bug in the hashtable implementation per se. You could argue that in the general case of a library hashtable one should prefer speed and predictability to DoS protection and use separate kind of HashTable for this kind of input. I am curious how companies will choose to patch this vulnerability.
Re: (Score:2, Interesting)
"should prefer speed and predictability"
This is rubbish bullsh!t. Randomized hash function are as simple as adding a simple XOR with a value generated randomly when the application starts up.
For every get(...) or contains(...) in your hash maps you have do a SINGLE ADDITIONAL XOR.
Your "perfs" argument is full bullsh!t.
Btw Perl does just this and even if *you* consider it is a feature to not use a randomized hash function, today Perl is fine while web servers using hashmaps written in other languages are no
Re: (Score:2)
You XOR the input, not the output.
Re: (Score:3)
To be fair I think the poster was trying for the "OMG Micro$oft fixed it before everyone else after 1 day" angle, but in doing so missed the rather critical point that the DDoS is only effective against web servers so most Windows machines won't need the update (since they don't serve web pages). I expect it will be pushed to all versions anyway as there may be other ways of exploiting the OS hash functions in this way, but at the moment it isn't like random Windows users will get hit by this.
RHEL Tomcat 5? (Score:2)
I see Tomcat 6 and 7 got fixes from Apache. I can't find a bugzilla for tomcat5 at Redhat, though sometimes they like to hide security work from us until the update is out (which just frustrates us, especially after public disclosure).
I assume they're working on it, since RHEL5 is so massively deployed.
Anybody see anything I'm missing?
Re: (Score:2)
Re: (Score:3)
Re: (Score:2)
Re: (Score:3, Informative)
No, this is not how hashtables work. The hashcode is not identity value but a means to sort elements into buckets for faster lookup. It won't get "confused" by equal hashes, it just gets somewhat slower when a large number of elements with equal hashes are added.
Re: (Score:2)
To be precise, it elements with equal *exit* hash values - the same hash key will simply overwrite prior values. Internally, the language runs a hash algorithm against the key and uses the resulting value to generate an index to the array that *actually* holds the key/value pair. If multiple keys hash to the same index, then the value will actually be another array, containing all the key/value pairs that mapped to that index. You then need to walk that index to find the key you're looking for.
The downside
That is *not* out-of-band (Score:4, Informative)
Out-of-band would involve them mailing a CD to recipients, or some other form of delivery other than the Internet.
The phrase for which you were searching is "off-schedule".
Re: (Score:2)
Since the affects servers, that would make a lot of sense too.
Re: (Score:2, Insightful)
No, I believe "out-of-band" is correct, if you go by the following definition:
"In general language, out-of-band refers to communications which occur outside of a previously established communication method or channel"
The "Method or Channel" in this instance is Patch Tuesday.
Re: (Score:3, Interesting)
You're wrong, though. Out-of-band has a very specific meaning. It refers to having a backup management channel that is independent from your main network in case you accidentally turn off the wrong port or get a cut. For example many of our Fiber Optic sites also have a dial-up modem tied to copper, just in case all the fiber goes down at once.
This security update is in no sense out of band, it's just expedited a bit.
Re:That is *not* out-of-band (Score:5, Interesting)
Out-of-band doesn't have a "specific" meaning, though, that's kind of the point. In your workplace, it may mean one thing, however in this context the meaning is different. It means something else entirely when you talk about network protocols, for example.
However, if you're still sure you're correct, rather than posting about it on slashdot, you might want to tell Microsoft themselves that they're using the wrong term: http://blogs.technet.com/b/msrc/archive/2011/12/28/advanced-notification-for-out-of-band-release-to-address-security-advisory-2659883.aspx [technet.com]
Re: (Score:2)
Citing the first (and only?) source to misuse the term is not citing an authority.
Re: (Score:3)
So because I only linked one source, it must be the ONLY one?
How about this one from 2008? https://msevents.microsoft.com/CUI/EventDetail.aspx?culture=en-US&EventID=1032393979&CountryCode=US [microsoft.com]
Or this one from last year? http://blogs.technet.com/b/msrc/archive/2010/09/30/q-amp-a-from-the-september-2010-out-of-band-security-release-webcast.aspx [technet.com]
Or this one from waaay back in 2006? http://blogs.technet.com/b/msrc/archive/2006/09/26/459194.aspx [technet.com]
And someone other than Microsoft: http://isc.sans.edu/diary.htm [sans.edu]
Re: (Score:2)
Those all talk about Microsoft, originator of the misuse of "out-of-band". It's all just parroting the same source, reporting what Microsoft called it.
One company's misused term in marketing does not an agreed-upon definition make. Find an independent source that doesn't source or reference Microsoft and its off-schedule releases. And not one you make yourself, either.
The term "off-schedule" already existed and is specific and precise. There's no just cause for expanding the definition of "out-of-band" to e
Re: (Score:2)
Ok then,
http://nakedsecurity.sophos.com/2011/09/17/oracle-issues-rare-out-of-band-update-for-apache-ddos-vulnerability/ [sophos.com] "Oracle issues rare out-of-band update for Apache DDoS vulnerability"
http://www.simplysecurity.com/2011/09/27/adobe-releases-out-of-band-patch/ [simplysecurity.com] "Adobe Releases Out-of-Band Patch"
http://publib.boulder.ibm.com/infocenter/director/v6r1x/index.jsp?topic=/di [ibm.com]
Re: (Score:3, Informative)
"Oracle issues rare out-of-band update for Apache DDoS vulnerability" [sophos.com]
"This is only the fifth time Oracle has issued an alert outside its routine quarterly patch cycle since introducing its own version of Patch Tuesday at the start of 2005."
That would be Microsoft's "Patch Tuesday". Oracle doesn't call it "out-of-band".
"Adobe Releases Out-of-Band Patch" [simplysecurity.com]
Adobe called it a "Security bulletin", and judging from when Adobe releases updates for Flash Player [adobe.com], I'm not even seeing a regular schedule to classify it as "out-of-band" as Microsoft defines it.
"Installing out-of-band updates for IBM BladeCenter devices using Telnet fails" [ibm.com]
They're actually talking about delivery of patches via FTP and T
Re: (Score:2)
Your arguments are getting more and more spurious. First It was because I only posted one source, then it was because I only posted Microsoft sources and now the sources I posted don't quite mention "out of band" in quite the way you like.
It doesn't matter, it's semantics and I'll refer to my earlier post - don't complain about it on Slashdot, complain about it to Microsoft since they're apparently the originator of this misused term.
Re: (Score:2)
Not unless the only date you can download your updates is on that single day of the month. The regular release date is not a method nor is it a channel. It's a schedule. This is out-of-schedule, or off-schedule.
"Rapid response" would be the marketable term they should have gone with.
Re: (Score:2)
That's not marketing friendly, that'd imply the regular response isn't rapid...
I'm also not sure I'd call it unusual (Score:2)
While MS normally schedules updates to make things easier for people, they have issued updates out of the regular schedule numerous times in the past. I don't know precisely what their criteria is but if something is critical enough (maybe easy enough to exploit, already in the wild, serious enough consequences) they'll release a patch ASAP rather than waiting for patch Tuesday.
I always get grief about it because of whiny grad students. We have a number of grad students that run lengthy simulations and can'
Technical Background (Score:5, Insightful)
Just to make it clear - this affects a whole lot of systems and is based on a flaw in the design of hash-tables:
http://packetstormsecurity.org/files/108209/n.runs-SA-2011.004.txt [packetstormsecurity.org]
Basically you can pre-calculate a huge set of POST parameter names which will all be hashed to the same value. Since these are stored in a hash-map by most web-frameworks - this will lead to a o(n) lookup time instead of a o(1) lookup time, when testing the hash-map for a given parameter name.
This will max out your cpu quite quickly depending on how many lookups you perform per request.
Since the attack has "script kiddie" difficulty, this needs to be patched ASAP by all vendors ... or we will see a lot a downtime on many public servers.
Re: (Score:3)
More importantly, although lookup is O(n), the insert growth is O(n**2). The request environment preparation for many web languages such as PHP, .NET, Java, Ruby, and Python will time out before script execution even begins (while maxing out a CPU for whatever the request timeout is, usually at least 30 seconds).
The vulnerability is essentially that it's easy to generate intentional key hash collisions for these hash table implementations. This class of vulnerability has been known about since at least 20
Re: (Score:2)
I can't answer for Microsoft or others, but if I had to guess, I'd say that although the class of vulnerability was know about, it wasn't considered to be much threat; the chances of this happening under normal circumstances are vanishingly small. So it was probably considered more of an artifact of the implementation than something exploitable. It seems like apparently only yesterday that someone put together that these linked hash maps are used in pretty much every web scripting language out there, and
Changing a hash function... (Score:2)
1) be at least as "strong" ( read: as hard to reverse ) as the old one
2) a manifest patch against the bug described in the OP's references, which, indeed, *does* look like a serious bug
3) be thoroughly tested against criteria 1 and 2
That is a helluvajob.
Re:Changing a hash function... (Score:5, Insightful)
This is not an issue with a hash function. This is a security issue that involves validating external inputs to a program before attempting to operate on them.
The web servers shouldn't be attempting to store these values in a hashtable at all. Sanity checks should be rejecting requests that have too many parameters in the first place.
Re: (Score:2)
Not at all. This is not a case of lack of input validation, this is a case of software not being able to handle a valid input correctly. The vulnerable code is a generic piece of code, it doesn't know what the higher level application considers valid.
You could "fix" it by having the higher level application tell the lower layer the maximum number of parameters, or even better a list of all per
Re:Changing a hash function... (Score:4, Informative)
Re: (Score:2)
Hopefully not too many people depend on hashCode() always returning the same value for identical objects between runs. Fixing this vulnerability, the way TFA recommends, would necessarily break this expectation. I see in the documentation [oracle.com] they word the contract in such a way that people should be scared off from doing it this way, but you never know :)
Re: (Score:3)
I don't know about Java, but for .NET there is a specific disclaimer that Object.GetHashCode() can not be relied upon to return the same value between different versions of the framework, or even between different runs - even for well-known value types such as int or string.
Re: (Score:2)
The real problem here is that it's fairly easy to compute a set of hash keys that are known to generate collisions on a specific hash table implementation. The easiest fix by far - the fix that perl implemented in 2003 - is to generate a random value when the hash is initialized, and XOR each incoming key with it before processing. That breaks collision prediction on the attacker's side quite effectively.
Re: (Score:3)
A more simple solution would be to simply go through submitted POST keys and filter out unexpected or illegitimate keys -- the application made the form, so it should know exactly what it should be getting back. If you load the key strings into a vector or an array, filter it, and THEN create a map/hash/whatever, you should be safe.
I admit this is an eye-opening vuln. I'd never thought twice about using tainted strings as hash keys.
Re: (Score:2)
I don't think you understand the vulnerability. By the time the POST parameters get to you, they may already be in a hashtable. For example $_POST in php.
Re: (Score:2)
Yeah, real languages don't do that, or they at least give you a way of avoiding that; Ruby doesn't compulsorily load post data into a hash, you can always handle a post body yourself and POST request handling is provided by a library, not bolted into the language and invoked automagically.
Re: (Score:2)
But in some frameworks that do this, you can actually intercept the data before that processing occurs, and perform pre-validation yourself if you wanted to. This is at least possible in ASP.NET (through creation of custom handlers) and I believe Java.
Re: (Score:2)
He's not right but it's relatively easy to find collisions in the fast hashing algorithms that platforms use, like adler or CRC32.
28th chaos communication congress revelead this (Score:5, Informative)
the Chaos Computer Club is doing their congress at the moment and the hash collision problem was topic yesterday:
28c3: Effective Denial of Service attacks against web application platforms
http://www.youtube.com/watch?v=R2Cq3CLI6H8
no fix for Python in the making (Score:5, Interesting)
Also the fixes PHP 5.4rc (and tomcat, and
Re: (Score:3)
According to these guys this attack on a 64bit Python system is impractical, and as the world is shifting to 64bit anyway the problem might solve itself given enough time.
The journalist is terribly confused (Score:2, Informative)
The journalist says the vulnerability resides in the "POST function" of... something? Then he mentions MD5 collisions, and goes on quoting extensively from a report by a security firm.
More technically accurate version:
Hash tables (key-value stores) use a hash function to generate an internal representation of the key. When accessing the hash, the key gets hashed and compared to the internal representation to find the correct value. If there are collisions for a certain key, the implementation must enumerate
This presentation at 28C3 (with video) (Score:5, Informative)
This research was presented by n.runs at the 28th Chaoas Communication Congress: http://events.ccc.de/congress/2011/Fahrplan/events/4680.en.html [events.ccc.de].
The presentation was recorded and can be viewed at http://www.youtube.com/watch?v=R2Cq3CLI6H8 [youtube.com].
If using PHP5, change max_input_time (Score:5, Informative)
I agree with others, this is not a Microsoft issue, it's an issue for all sysadmins.
Anyway, from http://packetstormsecurity.org/files/108209/n.runs-SA-2011.004.txt [packetstormsecurity.org] is this helpful bit to reduce your susceptibility to attack, if you're using PHP:
Re: (Score:2)
An easy solution to this was pointed out in that article: limit the number of input parameters.
And Apache Tomcat already has a release that does just this with a customizable property. The default is set to 10,000 parameters. If you use Tomcat as your servlet engine, then it should be resolved with 7.0.23 or 6.0.35.
A direct quote from the article:
Better Writeup (Score:5, Informative)
Here is a better writeup from Ars Technica: http://arstechnica.com/business/news/2011/12/huge-portions-of-web-vulnerable-to-hashing-denial-of-service-attack.ars [arstechnica.com]
From that page:
the flaw affects a long list of technologies, including PHP, ASP.NET, Java, Python, Ruby, Apache Tomcat, Apache Geronimo, Jetty, and Glassfish, as well as Google's open source JavaScript engine V8
the theory behind such attacks has been known since at least 2003
Klink and WÃlde showed that "PHP 5, Java, ASP.NET as well as V8 are fully vulnerable to this issue and PHP 4, Python and Ruby are partially vulnerable, depending on version or whether the server running the code is a 32-bit or 64-bit machine
The actual vulnerability seems to be that many web applications (or application servers or libraries or what have you) parse form data from HTTP POST requests into hash tables, using known hashing algorithms. If an attacker sends a POST request using specifically crafted parameter names that all hash to the same value, inserting these into the hash table will take O(n^2) time, which opens up affected software to a denial of service attack.
Re: (Score:3)
Indeed, and it sounds more like a programming flaw than a platform flaw. If you need a hash function with cryptographic properties, don't use MD5. It may not always be obvious, but if you work with unverified user input, chances are that you need some level of cryptographic strength.
It is however peculiar that MS rolls out an out-of-band patch for a DOS flaw. I suppose this means it has been exploited in the wild in several places, and MS is moving into "proactive mode" - which is rare enough an occasion
Re: (Score:2)
Indeed, and it sounds more like a programming flaw than a platform flaw. If you need a hash function with cryptographic properties, don't use MD5. It may not always be obvious, but if you work with unverified user input, chances are that you need some level of cryptographic strength.
This isn't an MD5 issue. I doubt that most of these hash table implementations use any cryptographic hash function (why bother? Cryptographic collision resistance is expensive and not generally relevant to hash table uses), but even if they used iterated SHA-512 interspersed with RIPEMD, TIGER and WHIRLPOOL in a pseudo-random sequence, the implementation would still be vulnerable.
How? Well, all the attacker has to do is to predict with reasonable accuracy the size of the hash table. Since the attacker
Re: (Score:2)
That's how perl was fixed - XOR each incoming key with a random value generated when the hash is initialized.
Re: (Score:2)
Easy patch? (Score:2)
The RC version of PHP has a new directive, max_input_vars. Should be easy to implement. The POST data come in as a string, just like a query string, as I recall it. So just count the number of ampersands.
Article says the DoS happens as the hash table is populated, so there is no easy fix for the PHP user. A patched version of PHP must be compiled. Or maybe some apache magic can be applied before the data hits PHP. Something in mod_rewrite in the .htaccess?
Re: (Score:2)
Apache has an input filter mechanism. Could also proxy I guess. Easy to detect the bad input, just a question of how to hook.
MaraDNS' Deadwood is immune (Score:4, Informative)
You know, I knew this issue would come out of the woodwork one day; I went to some bother to have a randomized hash compression function for MaraDNS 2.0's recursive resolver (Deadwood).
From the relevant man page [maradns.org] (this part was last updated in September of 2010):
Personally, I think it this is a pretty obvious attack to think of when designing a hash compression function.
Re: (Score:2)
Personally, I think it this is a pretty obvious attack to think of when designing a hash compression function.
I agree it is obvious. But it's also simple to avoid. And you don't even need high entropy for it. Storing a random number ONCE (like at install time) and then used in all instances would be resistant in most cases. So if /dev/urandom isn't available for some reason, that's not a show stopper (fall back to a hash of the install date, perhaps)
For some things I'm doing, I even skipped hash and went to BST. (My) BST (code) benched better than hash for scales up to what I usually do. I also made a HCBST (
Re: (Score:2)
You know, rather than making Windows users jump through stupid convoluted hoops just to get your program to run, why not take a few minutes to implement the same solution you do on *nix [microsoft.com] and just ask the OS for your entropy at runtime? Why do open source developers insist on half-assing it on Windows so much?
Re: (Score:2)
And you quite ably demonstrated my point as well. Rather than thinking, "hmm, maybe this will make my program better for my users - I should consider this", you say "pay me then maybe I will".
That, right there, is the problem with most open source project maintainers.
Privilege Escalation? (Score:2)
Am I missing something? The posts so far refer to this as a hash table collision DOS vulnerability, but MS categorizes it as "Elevation of Privilege" vulnerability.
--Joe
At this stage, why have a hash function at all? (Score:2)
Put the parameters into an indexed array and let the script that deals with the data sort it out. Much simpler and less likely to be exploited because you aren't doing calculations based on the input data.
Re: (Score:2)
It would work, one script would then check to see if the keys were one of year, month, or day. Another script would verify that it only got zip, city, or state. Those keys that it cared about, it could put those values into a hash table if it wanted, or not if it just used them right then and there. The problem is that framework like plone or rack or tomcat or whatever it is that calls your script doesn't know what are the variables that you will need. It puts them all in a hash. Oh sure that use an array t
web application firewalls (Score:2)
How will Dan Bernstein respond (Score:2)
How will Dan Bernstein respond to the discovery that his hash functions are insecure?
a) "I never said they were secure"
b) "They are secure, they were just implemented wrongly"
c) "You idiots"
No sream decoding? (Score:2)
1. Web Server receives complete POST string, splits the string into its paramter=value pairs and inserts these into a hashmap
2. The Web Service programmer then finds out which parameters where posted by issuing a lookup for each and every parameter the service knows about
Is it really that bad? So the 2,0 programmers cannot process data as streams and act upon the data as it is processed?
Update now available (Score:2)
http://technet.microsoft.com/en-us/security/bulletin/ms11-100.mspx [microsoft.com]
Re: (Score:1)
Yup. That is exactly what the Apache Tomcat people are doing: https://mail-archives.apache.org/mod_mbox/www-announce/201112.mbox/%3C4EFB9800.5010106@apache.org%3E [apache.org]
In short, sloppy programming.
Re: (Score:2)
Improve performance of parameter processing for GET and POST requests. Also add an option to limit the maximum number of parameters processed per request. This defaults to 10000. Excessive parameters are ignored. Note that FailedRequestFilter can be used to reject the request if some parameters were ignored. (markt/kkolinko)
Re: (Score:2)
if (paramHashValues.containsKey(key)) {
values = paramHashValues.get(key);
} else {
values = new ArrayList(1);
paramHashValues.put(key, values);
}
values.ensureCapacity(values.size() + newValues.length);
for (String newValue : newValues) {
values.add(newValue);
}
which means that if a hash-collision is detected the values are added to the valueset (instead of modifying the hash algorithm).