5 ms·

No matter what he tried to explain they just kept replying that he didn't qualify for the reward. It sounds like they have become super defensive about acknowle

by zmmmmm 13y ago

No matter what he tried to explain they just kept replying that he didn't qualify for the reward. It sounds like they have become super defensive about acknowledging bugs because the reporter will immediately try to claim a reward. If so, it's the exact opposite of the intent of the program. I once reported Chrome because it crashed when I tried to load a 65536x65536 bitmap image. Since it was a crash I, of course, claimed it was a security issue, in the hope that was enough to get a reward. Of course, they didn't accept that, but it does make me think the other side of this issue may be that Google is now receiving so many of these they are unable to properly evaluate them all and applying the "HR" solution (employ someone underqualified explicity to fob off as many people as possible so that only super-qualified candidates get through).

justinschuh 13y ago
I can assure you that Google takes VRP reports very seriously. Two members of Google security (f- and adobkin) have provided context elsewhere in this thread on the bug described in the post. As for the Chrome report you mention, if you provide the bug ID I can check. However, given your description, it definitely seems like the bug was closed because you were observing the intended behavior of terminating the renderer process on an out-of-memory condition. The bug reporting form links to guidelines on reporting security bugs, and explains why this specific case is not a security issue: http://www.chromium.org/Home/chromium-security/reporting-security-bugs#TOC-Signs-A-Crash-Is-Not-A-Security-Bug http://www.chromium.org/Home/chromium-security/reporting-sec...
- saurik 13y ago
  I shouldn't be able to terminate the rendering process, which contains the contents and information of numerous tabs by just loading a large image into it: it should realize the image is too large and stop loading it... otherwise that's a denial of service attack you can use against someone and potentially cause them data loss from one of the other tabs in that process. (That Chome shares processes between lots of tabs, by the way, was a massive disappointment after the original video that made it sound like tabs would all be isolated... it frankly is largely a worthless token show of security theatre to have things separated the way Chrome ended up doing.)
  - vwinsyee 13y ago
    > That Chome shares processes between lots of tabs, by the way, was a massive disappointment after the original video that made it sound like tabs would all be isolated I'm not an expert on sandboxing browser tabs, but so far I haven't had any (memorable) experience where a rogue Chrome tab crashed the whole browser. Just yesterday someone posted a jsfiddle on HN [0] that crashes tabs in Chrome, but the entire browser when opened in Firefox. [0] https://news.ycombinator.com/item?id=6358727 https://news.ycombinator.com/item?id=6358727
    - saurik 13y ago
      There is a difference between separating "web page rendering" from "browser UI" or "networking" and the kind of tab separation I am discussing: those are privilege separations, which at their bare minimum mean that when some JavaScript crashes, it doesn't take down the UI. This is both a functionality and a security benefit that I did not and will not argue against. Chrome, however, also claims to isolate tabs from each other, so that one tab cannot affect the behavior of another tab; but, in practice, I have tons of tabs that all have ten totally unrelated websites rendering in them (everything from my e-mail client to 4chan), so that isn't actually offering me any advantage: it is still possible for rogue websites that are able to exploit only their rendering process to steal data from any other website that ended up in the same process.
  - justinschuh 13y ago
    Attempting to recover from OOM is almost always a bad idea, which is why Chrome terminates processes by default on OOM. To underscore this point, I should note that I've found a number of serious vulnerabilities resulting from applications attempting to recover from OOM. Here's a detailed writeup of one I found in Firefox several years ago: http://blogs.iss.net/archive/cve-2008-0017.html http://blogs.iss.net/archive/cve-2008-0017.html As for how Chrome's process sharing works, it's opener based for Web content. That is, if one browsing context opens other browsing contexts (either via iframes or popups) where the opened context is retained by the opener, then they will run in the same process in order to preserve resources and the relationships required by Javascript. This means the process is shared in cases where the HTML standard explicitly requires that the child browsing context be able to navigate the parent opener or frame. So, at that point, required Web functionality achieves an equivalent to the DoS you mention. Process sharing can also be triggered when resource limits are reached or during page transitions, but that's rarely a significant factor in practice and not controllable by a Web site. And to be very clear, Chrome's process isolation is far from security theater. The sandbox prevents renderer processes from accessing or manipulating any system state directly. It's a hard security boundary that's been extremely effective in preventing exploits. It also allows Chrome to entirely isolate different classes of renderer processes from each other, such as those used for Web content versus filesystem, extensions, apps, or system settings. That stated, we're still working on improving Web content isolation because our final goal is to entirely isolate different origins in the same class. But doing so is far beyond anything attempted in a production browser before, and entails a massive engineering effort. The team working on that has various bugs you can follow in our tracker, and a public design document: http://www.chromium.org/developers/design-documents/site-isolation http://www.chromium.org/developers/design-documents/site-iso...
- vog 13y ago
  > As for the Chrome report you mention, if you provide the bug ID I can check. This demonstrates exactly what's wrong with Google's interpretation of "openness". Sure, if one finds some Google insider, one may get information. Normally (read: in almost all other bigger Free Software projects), one could simply have a look at the bug tracker on one's own, without being on the mercy of Google.
  - estel 13y ago
    Not usually for reported security vulnerabilities
    - Skalman 13y ago
      But I thought the point was that they didn't consider this to be a security vulnerability.
  - mineo 13y ago
    Having reported a bug in Chromium myself that I thought was security related (but in the end was not - better safe than sorry), I think it's a reasonable decision to not show security related bug reports/tickets from the general public - you'd otherwise present all security holes in the browser to every evil guy in the world on a silver platter.
  - justinschuh 13y ago
    I asked for the bug ID so that I could verify it was triaged properly, not because the report isn't public. Some reports (like security bugs) are initially private, as is typical in any open source project. However, security bug reports are made public as well at some after they're resolved. You can go ahead and see for yourself: https://code.google.com/p/chromium/issues/list https://code.google.com/p/chromium/issues/list
    - mpyne 13y ago
      For example, the KDE security mailing list is definitely private, and some KDE bugtracker bugs are private as well.
- pygy_ 13y ago
  It appears that phishing-related vulnerabilities do not qualify for the reward program. You may want to reevaluate your policy, because it is incredibly short-sighted. Phishing is one of the most effective attack vector (link to a page with a zero-day browser exploit), and even though it may not endanger data held by Google, it puts users at risk of ending up with malware that may steal much more than Google-held data.
cashmonkey85 13y ago
Why would you expect a reward for a bug just because it was a crash? I work in SVG and have reported a handful of crashes and never expected to qualify for their security reward.
- zmmmmm 13y ago
  Oh I absolutely didn't. I felt a bit bad afterwards for assigning it as a security bug. But that is really my point - when there's cash on offer people are apt to take a very liberal definition of what a security bug actually is.
ig1 13y ago
I recently reported a security issue in an API to a major tech vendor (not Google) and was shocked to get a reply from a "security analyst" at the firm who basically said it was a non-issue because it didn't occur when they went to the API url in their web browser. It's baffling that tech firms seem to have people without strong technical aptitudes responsible for incoming security reports.

by zmmmmm 13y ago

justinschuh 13y ago

I can assure you that Google takes VRP reports very seriously. Two members of Google security (f- and adobkin) have provided context elsewhere in this thread on the bug described in the post. As for the Chrome report you mention, if you provide the bug ID I can check. However, given your description, it definitely seems like the bug was closed because you were observing the intended behavior of terminating the renderer process on an out-of-memory condition. The bug reporting form links to guidelines on reporting security bugs, and explains why this specific case is not a security issue: http://www.chromium.org/Home/chromium-security/reporting-security-bugs#TOC-Signs-A-Crash-Is-Not-A-Security-Bug http://www.chromium.org/Home/chromium-security/reporting-sec...

saurik 13y ago
I shouldn't be able to terminate the rendering process, which contains the contents and information of numerous tabs by just loading a large image into it: it should realize the image is too large and stop loading it... otherwise that's a denial of service attack you can use against someone and potentially cause them data loss from one of the other tabs in that process. (That Chome shares processes between lots of tabs, by the way, was a massive disappointment after the original video that made it sound like tabs would all be isolated... it frankly is largely a worthless token show of security theatre to have things separated the way Chrome ended up doing.)
- vwinsyee 13y ago
  > That Chome shares processes between lots of tabs, by the way, was a massive disappointment after the original video that made it sound like tabs would all be isolated I'm not an expert on sandboxing browser tabs, but so far I haven't had any (memorable) experience where a rogue Chrome tab crashed the whole browser. Just yesterday someone posted a jsfiddle on HN [0] that crashes tabs in Chrome, but the entire browser when opened in Firefox. [0] https://news.ycombinator.com/item?id=6358727 https://news.ycombinator.com/item?id=6358727
  - saurik 13y ago
    There is a difference between separating "web page rendering" from "browser UI" or "networking" and the kind of tab separation I am discussing: those are privilege separations, which at their bare minimum mean that when some JavaScript crashes, it doesn't take down the UI. This is both a functionality and a security benefit that I did not and will not argue against. Chrome, however, also claims to isolate tabs from each other, so that one tab cannot affect the behavior of another tab; but, in practice, I have tons of tabs that all have ten totally unrelated websites rendering in them (everything from my e-mail client to 4chan), so that isn't actually offering me any advantage: it is still possible for rogue websites that are able to exploit only their rendering process to steal data from any other website that ended up in the same process.
- justinschuh 13y ago
  Attempting to recover from OOM is almost always a bad idea, which is why Chrome terminates processes by default on OOM. To underscore this point, I should note that I've found a number of serious vulnerabilities resulting from applications attempting to recover from OOM. Here's a detailed writeup of one I found in Firefox several years ago: http://blogs.iss.net/archive/cve-2008-0017.html http://blogs.iss.net/archive/cve-2008-0017.html As for how Chrome's process sharing works, it's opener based for Web content. That is, if one browsing context opens other browsing contexts (either via iframes or popups) where the opened context is retained by the opener, then they will run in the same process in order to preserve resources and the relationships required by Javascript. This means the process is shared in cases where the HTML standard explicitly requires that the child browsing context be able to navigate the parent opener or frame. So, at that point, required Web functionality achieves an equivalent to the DoS you mention. Process sharing can also be triggered when resource limits are reached or during page transitions, but that's rarely a significant factor in practice and not controllable by a Web site. And to be very clear, Chrome's process isolation is far from security theater. The sandbox prevents renderer processes from accessing or manipulating any system state directly. It's a hard security boundary that's been extremely effective in preventing exploits. It also allows Chrome to entirely isolate different classes of renderer processes from each other, such as those used for Web content versus filesystem, extensions, apps, or system settings. That stated, we're still working on improving Web content isolation because our final goal is to entirely isolate different origins in the same class. But doing so is far beyond anything attempted in a production browser before, and entails a massive engineering effort. The team working on that has various bugs you can follow in our tracker, and a public design document: http://www.chromium.org/developers/design-documents/site-isolation http://www.chromium.org/developers/design-documents/site-iso...
vog 13y ago
> As for the Chrome report you mention, if you provide the bug ID I can check. This demonstrates exactly what's wrong with Google's interpretation of "openness". Sure, if one finds some Google insider, one may get information. Normally (read: in almost all other bigger Free Software projects), one could simply have a look at the bug tracker on one's own, without being on the mercy of Google.
- estel 13y ago
  Not usually for reported security vulnerabilities
  - Skalman 13y ago
    But I thought the point was that they didn't consider this to be a security vulnerability.
- mineo 13y ago
  Having reported a bug in Chromium myself that I thought was security related (but in the end was not - better safe than sorry), I think it's a reasonable decision to not show security related bug reports/tickets from the general public - you'd otherwise present all security holes in the browser to every evil guy in the world on a silver platter.
- justinschuh 13y ago
  I asked for the bug ID so that I could verify it was triaged properly, not because the report isn't public. Some reports (like security bugs) are initially private, as is typical in any open source project. However, security bug reports are made public as well at some after they're resolved. You can go ahead and see for yourself: https://code.google.com/p/chromium/issues/list https://code.google.com/p/chromium/issues/list
  - mpyne 13y ago
    For example, the KDE security mailing list is definitely private, and some KDE bugtracker bugs are private as well.
pygy_ 13y ago
It appears that phishing-related vulnerabilities do not qualify for the reward program. You may want to reevaluate your policy, because it is incredibly short-sighted. Phishing is one of the most effective attack vector (link to a page with a zero-day browser exploit), and even though it may not endanger data held by Google, it puts users at risk of ending up with malware that may steal much more than Google-held data.

cashmonkey85 13y ago

Why would you expect a reward for a bug just because it was a crash? I work in SVG and have reported a handful of crashes and never expected to qualify for their security reward.

zmmmmm 13y ago
Oh I absolutely didn't. I felt a bit bad afterwards for assigning it as a security bug. But that is really my point - when there's cash on offer people are apt to take a very liberal definition of what a security bug actually is.

ig1 13y ago

I recently reported a security issue in an API to a major tech vendor (not Google) and was shocked to get a reply from a "security analyst" at the firm who basically said it was a non-issue because it didn't occur when they went to the API url in their web browser. It's baffling that tech firms seem to have people without strong technical aptitudes responsible for incoming security reports.