

The Ghost in the Browser: Analysis of Web-Based Malware [pdf] - sytelus
https://www.usenix.org/legacy/events/hotbots07/tech/full_papers/provos/provos.pdf

======
jcr
It's a great paper. Nearly anything by Neils Provos is great, but this is from
2007 and a lot has changed since then. You should probably edit the submission
title and append "(2007)" to it.

------
pdkl95
From the paper's conclusion:

    
    
        ...adversaries take advantage of powerful scripting languages such as Javascript
        to determine exactly which vulnerabilities are present on a user’s computer and
        use that information to request appropriate exploits from a central server.
    

Even though this has been a well-known problem for a long time now, we still
have a HUGE number of people here on HN that trash talk the very idea of not
using javascript. An industry is in a very bad place when using the latest fad
tool (e.g. Angular) trumps user safety.

~~~
xyzzy123
Approximately 1% (order of magnitude) of users have JS disabled. If users wish
to disable it they can, but most of the web will break.

I don't particularly see this as an indictment of the industry, rather, it's
an indication of the risk-benefit trade-off that most people are willing to
make. A little risk, a lot of functionality.

Put a different way; driving is WAY more of a risk, but it doesn't seem to
stop people doing it.

We've mostly gotten rid of Java and Flash at this point. That seems rational.
The investment in browser (and JS engine) security at this point is massive.
If you've got missile launch codes on your computer or something, by all
means, don't browse! (or browse with JS disabled, or use Qubes, or otherwise
sandbox your browser).

Realistically, at any given point in time my browser IS vulnerable - but on
the other hand, my CC details and DOX aren't worth burning a reliable 0day on,
so I'm cool with JS enabled.

~~~
pdkl95
So I'll take that as yes, you insist that people must accept additional risks
to red your pages. You place ease of development (or maybe unnecessary-but-
shiny features) over the safety of users.

> 1%

That just proves my point about how widespread this disregard for safety is in
this industry. Saying "but those people make broken products as well!" isn't a
justification to do so yourself.

> driving

is off topic, and in no way comparable. I am not being forced to accept risk
from driving to read document or submit a simple form.

> Java and Flash

Not documents. More importantly, this is another example where saying "but he
did it to!" isn't a justification.

> missile launch codes

This is just cheap hyperbole intended to distract.

> don't browse [unless you let us force risk on you]

At least you admit that you agree with this ultimatum.

> my browser IS vulnerable

Yes, it probably is - so maybe you should start to work on fixing that
situation. A good place to start would be limiting the use of the main vectors
for infection... which is javascript. The paper even discusses (and I quoted)
how the use of javascript enables auto-selection of attacks.

> my CC details and DOX aren't worth

Ahh, the "but I'm not interesting enough to be a target" fallacy, where you
only consider targeted attacks.

~~~
xyzzy123
I respect your opinion, but still feel that you fail to understand the
fundamental nature of risk.

P.S: I write browser exploits (mostly FF, I'm not pro enough to do Chrome!).
Usually use-after-free. Myself and my colleagues still browse with JS on. BTW,
NoScript bypass is do-able.

~~~
slasaus
Can you maybe elaborate on the main non-js vectors? I know image/video is one,
is webgl/canvas maybe a big one? or webrtc? Or would you say js is by far the
biggest vector? I currently browse with developer edition (daily patches) with
noscript and requestpolicy to make firefox as secure as I can but I still feel
using a browser, and Firefox in particular is very unsafe practice and the
code is a mess. Am I right in this as far as you know?

~~~
xyzzy123
JS is by far the biggest vector. Even if you have a good bug in another
component (those you listed are good candidates) you will typically need JS to
massage the heap or trigger it.

SVG is another good source of bugs that comes to mind.

I don't think FF code quality is particularly worse than other browsers. Part
of the problem is that it is simply a very large very public project. Some of
the code is very old. Mainly though, they have been a bit slow to implement
architectural features (e.g. privilege separation / sandboxing) which would
improve resilience.

