4 ms·
>Do you actually have data to back that up, or are you just going by an assumption? An assumption. The idea is that conducting more malicious activity is gener
by Nadya 8y ago
>Do you actually have data to back that up, or are you just going by an assumption?
An assumption. The idea is that conducting more malicious activity is generally easier to spot than conducting less malicious activity and trying a wide range of exploits is more likely to be noticed than a smaller, possibly more targeted exploit. Script kiddies attempt a wide range of exploits when they're going after a single target. For example, throwing any and all known vulnerabilities against a website hoping it is hosted with an outdated version of Wordpress in an attempt to gain access. But unless you're going for attention and de-facing the home page, once you're in you want to draw as little attention to what you're doing as possible. OTOH, they might throw everything and the kitchen sink in under the assumption that they'll be caught quickly so they want to capture as much as possible before they're kicked out.
>...Because to me it seems likely that there are blobs of JS that look for a wide number of vulnerabilities floating around...
I browse with Javascript disabled. I use Tampermonkey and Stylish to inject CSS and Javascript that I write (and therefore trust) to pages I use frequently enough to justify the time spent on restoring certain functionality.
- kbenson 8y ago> The idea is that conducting more malicious activity is generally easier to spot than conducting less malicious activity and trying a wide range of exploits is more likely to be noticed than a smaller, possibly more targeted exploit. I understand the idea, I just think some assumptions that go into it are wildly unproven. I would think you're just as likely (if not more likely) to be exposed through a high traffic site that is dangerous for a very short period of time than a low traffic site that's exposed for a longer period. E.g. if nytimes.com is exploited, there's probably a window of minutes to an hour before it's noticed and fixed, and the fix make take as long or longer to happen than the first notification of a problem. In that scenario, the amount of time unnoticed reduced by stacking every exploit you can think of is fairly minimal, and it likely doesn't reduce the time to fix after notification at all. So, if this assumption any less possible than yours? The only difference is that whether my scenario is right or wrong, it promotes behavior that doesn't leave you more vulnerable to exploitation by random sites, while for yours if you're wrong (and you act on it, as you are) it leaves you more vulnerable. >>...Because to me it seems likely that there are blobs of JS that look for a wide number of vulnerabilities floating around... > I browse with Javascript disabled. Okay, then image library exploits, or css parsing exploits, or any number of other things. For example, ambiguously listed stuff like this[1], or this[2] or this[3] or this[4]... or how about I just point you at a bigger list[5] (code excution exploits for Firefox reversed by date, with severity rating over 9. There are hundreds). It's not like Javascript has been the only attack vector of the last few years. I have no idea how many of these affect that Firefox version. My guess is it's more than two or three. 1: https://www.cvedetails.com/cve/CVE-2016-2807/ https://www.cvedetails.com/cve/CVE-2016-2807/ 2: https://www.cvedetails.com/cve/CVE-2016-2806/ https://www.cvedetails.com/cve/CVE-2016-2806/ 3: https://www.cvedetails.com/cve/CVE-2016-2804/ https://www.cvedetails.com/cve/CVE-2016-2804/ 4: https://www.cvedetails.com/cve/CVE-2016-1945/ https://www.cvedetails.com/cve/CVE-2016-1945/ 5: https://www.cvedetails.com/vulnerability-list.php?vendor_id=452&product_id=3264&version_id=&page=1&hasexp=0&opdos=0&opec=1&opov=0&opcsrf=0&opgpriv=0&opsqli=0&opxss=0&opdirt=0&opmemc=0&ophttprs=0&opbyp=0&opfileinc=0&opginf=0&cvssscoremin=9&cvssscoremax=0&year=0&month=0&cweid=0&order=1&trc=447&sha=2ec9e591f4a35d9c40d5f6493400c4fb4ee1c03b https://www.cvedetails.com/vulnerability-list.php?vendor_id=...
- Nadya 8y agoI addressed that in the response - and admitted that, yes, it is an assumption against the largest attack vectors. >OTOH, they might throw everything and the kitchen sink in under the assumption that they'll be caught quickly so they want to capture as much as possible before they're kicked out. If I felt the risk was large enough to be concerned over - I'd fork and backport the patches and compile a personal version of FF 36 with critical bugs patched. I'll be honest in "possibly execute arbitrary code via unknown vectors" is not one of my highest security concerns and a concerning amount of these are only possible when running Javascript. In fact, the most concerning issues I saw are video codec related. Reading a few of them, they require me to decode/play the video in the browser to trigger so I can probably avoid that by downloading videos to watch locally in a media player instead of through Firefox. The severity of a bug doesn't matter to me as much as how trivial it is to exploit and how it needs to be exploited.