AwSnap – This link crashes Chrome | Hacker News Reader

AwSnap – This link crashes Chrome

github.com

71 pointsjlblatt40 comments

I'm pretty sure this is https://code.google.com/p/chromium/issues/detail?id=464270, which was fixed by https://codereview.chromium.org/1007323003.

Wow, that's an even better guess than the other (not mine) I posted: https://news.ycombinator.com/item?id=9326350

It's not just a guess, I broke it and I fixed it :)

Can I ask why you took the approach of making a Github repo to post this rather than filing a Chromium bug?

I did file a Chromium bug last week, #472347. I filed under security (as I was unsure) so it's not public, but it was pretty much immediately marked as 'Won't Fix'. Hence the repo ;)

Now this is interesting, especially the lack of a reply.

I wouldn't call marking the bug as WONTFIX a "lack of reply".

I see, I wasn't clear.

I talked about the lack of reply to the comment where this was pointed out.

Just asking why he didn't it and then leaving the conversation possibly means he either didn't wait for the answer or was bothered with it?

Sorry, last night HN didn't show me a "reply" button on the thread, so I thought maybe it tapped out at a depth of four? I'm not dodging :) [edit: does HN have account score thresholds at which different features get enabled?]

I don't have security-bugs access, but I explained offline to the OP that "Won't Fix" covers a lot of cases, including "already fixed" / "duplicate", not simply "your bug report is being ignored".

OP also sent me some more information about the BrowserStack setup, and it looks like both the M42 and M43 builds that OP was testing against are nearly a month old and before the fix (merged to M42 late in beta phase, M43's still in dev/canary stage).

TY, I'll update the readme.md when I get home tonight.

And you are right, it was initially marked as "Won't Fix" because it was not immediately reproducible, but further research yielded it being discovered as an "already fixed" dupe.

FYI it seems there is a minimum age (a minute or so) to a comment in order to reply. At least that was my experience last night.

>Sorry, last night HN didn't show me a "reply" button on the thread, so I thought maybe it tapped out at a depth of four?

Aha, the automatic flamewar limiter I guess. Happens to me as well. (clicking on the xx minutes ago link seems to help most of the time.)

> I don't have security-bugs access, but I explained offline to the OP that "Won't Fix" covers a lot of cases, including "already fixed" / "duplicate", not simply "your bug report is being ignored".

I don't know what I'd do if anyone reporting to me used wontfix for all those kind of cases. It doesn't exactly encourage bug reporting.

The dev reached out to me privately, I wouldn't infer anything based on the responses here.

Good to hear! Thanks for updating me.

Tangentially related, I was performing an analysis of the billions of links available in Common Crawl[1] and ran across an interesting error: there was one link where the port number was 18779690999[2].

The library I was using converted the port text into a 32 bit integer but the library didn't account for the possibility that someone supplied a port well over the 32 bit int limits. I was curious how many tools that use URLs would suffer similar fates and whether there might be any interesting security vulnerabilities.

Just goes to show, no matter how much crazy you've seen, there's likely crazier things hidden from you across the Internet ;)

[1]: http://commoncrawl.org/ [2]: https://twitter.com/Smerity/status/576339945041707008

The port number is supposed to be a 16-bit number though. So, anything above 65535 is malformed.

http://en.wikipedia.org/wiki/Port_%28computer_networking%29

Agreed that it's malformed. My point was more that I'm curious how many other libraries fail badly when confronted with an unexpectedly large port. It's the edge cases / "no-one would ever be silly enough to do that" that quite frequently lead to security issues =]

Yes, that's why I feel like this is more significant than a simple crash at first glance- no one would purposefully craft a 256+ unchecked character URL, unless they are being malicious, in which case they absolutely will craft a 256+ unchecked character URL.

URLs can definitely get rather long if they contain lots of query data, and the de-facto limit seems to be around 2KB[1]. It's still not acceptable for such URLs to crash the browser though.

[1] http://stackoverflow.com/questions/417142/what-is-the-maximu...

Sure looks like a toll-free phone number: 1-877-969-0999. Google hints relation to reporting natural gas leaks.

Edit - followed links

I've created something similar but for Firefox: http://crashfirefox.com/

Have added new crash options for users with NoScript (even if you're blocking 302s - try right clicking).

Hah, that click was definitely my karma for today, ty.

But the reason I posted this is because it doesn't rely on Javascript to eat up memory- anyone can post a malformed/long link to a web forum and crash the thread/site for other Chrome users immediately, without clicking thru.

And it just keeps going, love it

    ➜  ~  curl http://crashfirefox.com/

    ....................../´¯/)
    ....................,/¯../
    .................../..../
    ............./´¯/'...'/´¯¯`·¸
    ........../'/.../..../......./¨¯\
    ........('(...´...´.... ¯~/'....')
    .........\.................'...../
    ..........''...\.......... _.·´
    ............\..............(
    ..............\.............\...
        SNITCHES GET STITCHES

    ....................../´¯/)
    ....................,/¯../
    .................../..../
    ............./´¯/'...'/´¯¯`·¸
    ........../'/.../..../......./¨¯\
    ........('(...´...´.... ¯~/'....')
    .........\.................'...../
    ..........''...\.......... _.·´
    ............\..............(
    ..............\.............\...
        SNITCHES GET STITCHES

    ....................../´¯/)
    ....................,/¯../
    .................../..../
    ............./´¯/'...'/´¯¯`·¸
    ........../'/.../..../......./¨¯\
    ........('(...´...´.... ¯~/'....')
    .........\.................'...../
    ..........''...\.......... _.·´
    ............\..............(
    ..............\.............\...
        SNITCHES GET STITCHES


    ➜  ~  curl http://crashfirefox.com | wc -l
      % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                     Dload  Upload   Total   Spent    Left  Speed
    100 3613k    0 3613k    0     0  2020k      0 --:--:--  0:00:01 --:--:-- 2019k
      120000

Hah, I did the same thing, but it's not too hard to get past:

    curl -i -H 'User-Agent: Firefox' crashfirefox.com | head -n 80 | cut -b 1-100

Pushing browsers to their resource limits is fun... and makes me think that we should really have configurable limits to stop the browser consuming all RAM and crashing or affecting other applications' performance. A policy like "maximum 75% of available RAM" with a suitable cessation of further rendering when that limit is reached, with an error message, would be far better than forcing itself and all other apps into swapping and then crashing.

I hope this doesn't come across as negative but why post this on HN? Why not just file a bug on crbug.com? Browsers have bugs, all them. It seems kind of negative to turn it into a spectacle rather than just be kind and report the bug to the team.

Totally valid, and not negative at all. See: https://news.ycombinator.com/item?id=9326370

Browser makers need pressure to prioritize robustness. Otherwise, to be competitive with each other, they will prioritize features much more highly, and we can see the results today. "Browsers have bugs, all of them." ...but we're not talking about very-tricky-to-trigger bugs found a couple of times a year, we're talking about 30 every 6 weeks, in various subsystems.

I was initially turned off from Chrome in its early versions because it seemed that tabs crashed much more easily, since it wasn't as big a deal to have a tab crash. Firefox crashes as a whole, so it has much more motivation to diligently make sure its subsystems are not prone to crashing on high-level documents / languages, however malformed they may be.

But as was posted below, it's still quite easy to lock up Firefox. So I applaud crashfirefox.com as well as this Chrome demonstration, they're needed to keep the balance between robustness and new features.

It seems that the author did file a bug report and it almost immediately got marked WONTFIX:

https://news.ycombinator.com/item?id=9326370

Interestingly enough the links on Reddit don't seem to crash Chrome but the cortexture.net link from Github does. I'm running Chrome 41.0.2272.101 m (64-bit) on Windows 8.1

It seems hit or miss so far- Shardj just pointed out that https:// doesn't seem to crash at all.

That might make sense, since I'm seeing the same behaviour but have SSL enabled for Reddit.

Could be. My concern is:

1) Most people don't have SSL enabled for most (if any) sites that are optional.

2) Most normal users are using the standard build for MacOS/Win, not the dev channel, and not Linux.

3) This requires no XSS or anything remotely tricky. Just a couple hundred bytes of HTML, and that's it.

4) Most web forum filters and formatting code (including Markdown) let this thru just fine.

Maybe I'm blowing it out of proportion, but if you wanted to be a jerk to a whole lot of people very easily, you probably could.

EDIT: Grammar

Oh, for sure. There are plenty of attack vectors for this sort of thing, I just find the SSL behaviour interesting.

Interesting. Confirmed crash on Ubuntu 14.04, version 42.0.2311.50 beta (64-bit). It crashes only the tab ("He's dead, Jim"), not parent Chrome process.

Yup, it's not "serious", but could be used to DOS I believe.

It doesn't work on Latest Chrome beta or hacker news.

But a HK clone was crashed.

http://news.dbanotes.net/

Yup, seems to be fixed.

Suggestion from a reply to my bug report (filed under security so it's non-public) points to a dupe of:

https://code.google.com/p/chromium/issues/detail?id=472899

and fixed in:

https://chromium.googlesource.com/chromium/src/+/5922e15ca3d...

FWIW

>or hacker news

Its because HN defaults to https. Https rendering of a site seems to be unaffected by this bug.

Yup.

<a href="http://Lorem ipsum Culpa labore qui culpa enim nostrud eiusmod ullamco anim in dolor consequat voluptate in in laboris consequat dolor occaecat minim aliqua quis id in Duis eiusmod amet id do ex do dolore dolor anim sit deserunt do.">Hello World!</a>

Reply on news.ycombinator.com