Re: html input values and resource consumption

[Xander Teunissen <Ueberschim () schimmetje com>]

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