Browsers don't warn about these pages because the content they serve can successfully execute a code injection attack against the browser itself (eg. buffer overflow, pointer corruption, etc) but because some pages serve malware and use social engineering to persuade less savvy users to run them. They may also block pages that exploit known vulnerabilities in 3rd party plugins.
Code injection vulnerabilities in widely used software are rare these days. And a lot more difficult to exploit reliably thanks to process hardening techniques such as Address Space Layout Randomization, canaries surrounding important pointers on the stack, out of bound management of heap memory, another variety of canaries in the heap called "guard pages", forced mapping of the null pointer, making writable memory non-executable, process separation and privilege separation, etc.
Then there is the whole class of attacks that arise from the details of maintaining session over HTTP, a stateless protocol: Cross Site Scripting (XSS) and Cross Site Request Forgery (XSRF). The non-persistent (aka "reflective") variety of XSS and XSRF need to be launched from pages which users must be lured to. The malware filters need to warn users before these pages load and the user is exploited. These are not vulnerabilities in the browser, they arise from server side code that doesn't filter input appropriately considering the context.
Because of their reach ad networks are obvious targets for serving malicious content. Attackers love to get their code in there, and ad network operators are far from perfect when it comes to filtering it out.
False negatives and positives happen.
Want DP delivered to your inbox daily? Subscribe here:
Content of posts and comments on the Daily Paul represent the opinions of the original posters, and are not endorsed, approved, or otherwise representative of the opinions of the Daily Paul, its owner, site moderators or Ron Paul. Thi