Hello Henri, Friday, June 22, 2001, 10:35:43 PM, you wrote: HT> I'm not sure wether being able to slow, DoS or crash a browser is worth HT> talking about in a security forum. We-eell there's probably something to say for both sides on that, but I tend to agree with you. Then again, there've been so many of 'em lately, let's assume one more isn't a crowd for the moment. HT> I suspect every web developer that has to get his code to work on HT> multiple browsers knows at least half a dozen ways to do so on each HT> version, although they don't think of it as neat 0-day exploits, but HT> just as bugs they have to work around to have their stuff working HT> right. Hmm I'm sorry but I missed the part where I mentioned this being a neat 0-day exploit thingie.. which brings us back to the "talking about this in a security forum" remark. Most security problems (again, I'm not claiming this is one, I just wondered about something and asked a question) actually are bugs aren't they? Strange thing that. When playing with the input field size it's the whole machine whose resources get hogged, which puts it just about a very small persons step (let's not get the Campaign for Equal Heights upset.. ehm.. ok nevermind, probably not for a security forum either :) beyond your mere everyday (altough every hour is more appropiate somedays I'd have to agree) browser crash. Still, appropiateness is probably a discussion without end, something like the hacker/cracker thing, for which I don't feel that much at the moment. HT> Maybe that will change over time as more stable browsers come out, and HT> then people will stop thinking it's normal for a browser to crash or HT> misbehave in any way. Hehe, "I have a dream".. HT> Now, while I'm here.. a limitation with your attack is that your web HT> server has to send a lot of data to hurt the browser a bit. Using HT> client-side scripting would make it a lot faster to send, while HT> achieving the same result. HT> <script>for(b="A";1;b+=b);</script> HT> For example, that script create strings of 1, 2, 4, 8, 16, ... HT> characters. Only the latest computed string has a reference to it, so HT> every previous strings should eventually get garbage collected. This HT> one-liner makes netscape 4 jump, and apparently stay, to 150M on linux, HT> but doesn't kill it (I'm sending this mail from the same instance) HT> Opera 4 wasn't that lucky, and died shortly after reaching 50M. Nah. I know what you mean, but the part actually interesting me was something I observed initially with MSIE5 on my Win2k box. The size of the value inside the input field, cramps up an "equal" part in the working memory or so it seems. If the field is bigger, the amount of mem taken is as well. I don't care much for the loop, altough above is smoother of course, but it seems to be more or less the size that counts (who'd have thought? :). Should that be going there? Probably not. Again, you're right to say that client side DoS'es are all over the place, I was just a bit curious how you would go about implementing the function of a variable sized field like a textfield and at the same moment limit its size to prevent things like this. But that seems rather the wrong approach, since I don't think this should be taking up increasing amounts of memory in the first place? But ok, maybe it's for vuln-bug instead of vuln-dev, still had me wondering though.. wondering is good, I like wondering.. Cheers, Xander _____________________________________________________________ Sign up for FREE email from Schimmetje.com at http://www.schimmetje.com
This archive was generated by hypermail 2b30 : Sat Jun 23 2001 - 20:16:41 PDT