In this case, it was disguised as an advertisement but it was not running on an advertisement server. My adblocker did not catch it. It was injected into the page as an iframe twice. Once disguised as an ad ([IP-address]/ad.php), another time with just the IP-address of the server. I guess it was included a second time in case and adblocker catched the first one. Because it doesn't make sense to include the same exploit twice, unless I am missing something?

How did you detected it ?

The script triggered a file dialog showing it was trying to access a local file. I opened the Developer Tools and saw all kinds of other files being accessed, including my private and public keys. I nearly got a heart attack. I quickly revoked all SSH keys and started monitoring the requests to narrow it down before I submitted the bug ticket with all the information I had, including the exploit script that was executed.

Update: I played around with the exploit some more to find out what exactly triggered the file dialog. Turns out my OS (Ubuntu 15.04) actually saved me.

When you try to open a file with Firefox it will first try to map the file to a mimetype using the ExternalHelperAppService (https://developer.mozilla.org/en-US/docs/How_Mozilla_determi...). In case a mimetype is found, a file dialog is shown so you can open the file with the right application, in case it is not, the contents of the file will be displayed in the browser. In this case my OS provided the ExternalHelperAppService with a mimetype for one of my public keys with the .pub file extension: application/vnd.ms-publisher. Of course that's not the correct mimetype for the public key file, but that's basically what saved me by showing a file dialog because it found a mimetype. All other files had no file extension so no mimetype was found.

I also discovered that my private keys were all encrypted with a passphrase so even though they have been compromised it was not as bad as I initially believed.

By that logic it's more like an argument for disabling JS entirely - there is nothing about this that's specific to ads, and the reporter has speculated that it was placed by an attacker and only disguised as an ad.

Not executing any JS is safer, sure, but that's beside the point. If you strive for absolute security, power off your computer and never touch it again. This is about what you can do to improve the situation without impairing usability.

An adblocker doesn't impact usability (in most cases, it improves it significantly, through lower page load times and less space occupied by non-content), but prevents the vast majority of malvertising. Blocking all Javascript blocks all of them, but makes the modern web nearly unusable.

Unfortunately, an adblocker impacts income of site owners. Otherwise, I would have used these programs since a long time, but now my conscience does not allow it.

Well, they can ask my conscience to not run an adblocker because otherwise it impacts their income. If it was just that.

But they cannot ask my conscience to open myself up to security issues because otherwise it impacts their income.

(note that I have read the rest of the thread and am aware that simply running an adblocker wouldn't have prevented this exploit)

(second note/disclaimer is that I do run µBlock, for the personal reason that I feel they also cannot ask my conscience to open my attention to energy-draining distractions because otherwise it impacts their income)

Note that uBlock can be configured to block third party frames, which would have prevented the exploit

I don't want to get into a discussion about ad-based business models and the moral discussion. For me, the trade off definitely favours security. I also just can't concentrate when the page is littered with flashing ads. Thus for me, alternative to adblockers is not seeing ads, it's not visiting the sites because I'm not willing to put up with that for content that very like isn't worth the ad bombardment.

I do block JS by default. If it's a site that won't render something readable without JS, I usually just move on. If it's one that I really need to interact with I'll enable it for that site, which does open some risk, but this approach generally makes drive-by exploits less likely.