Hacker News new | comments | show | ask | jobs | submit login

The source, with more details and the links to the documents:

The Intercept: "Popular Security Software Came Under Relentless NSA and GCHQ Attacks"

https://firstlook.org/theintercept/2015/06/22/nsa-gchq-targe...

The Intercept checked some claims themselves: "Testing performed by The Intercept last month on a trial copy of “Kaspersky Small Business Security 4” determined that, while some traffic was indeed encrypted, a detailed report of the host’s hardware configuration and installed software was relayed back to Kaspersky entirely unencrypted. By the time of publication, Kaspersky told The Intercept via email, it was unable to reproduce these results."




Yes. Url changed from http://techcrunch.com/2015/06/22/nsa-has-reverse-engineered-..., which points to this.


Maybe mods can change the link?


Kaspersky traffic being easy-ish to intercept may be a feature, not a bug, considering Kaspersky's ties to the Putin regime. Some details here: http://www.wired.com/2012/07/ff_kaspersky/

I think AV is a tricky thing as it gives ring 0 (or equivalant) access to workstations and has its fingers in pretty much everything. Intelligence agencies probably see it as a huge win if they can commandeer one without anyone knowing.

Shame FOSS AV never really took off. I wouldn't be surprised if all AV had some relationship with their host government.


Is there a model for giving the maintainers a larger incentive to be honest, than the incentive that could be provided by a bad player?

To restate - Many FOSS maintainers live a ramen lifestyle. If someone either A. wanted a zero day exploit, or B. wanted a virus to be ignored, they might be able to pay the maintainer enough to violate ethics. Is there a way to incentivize maintainers enough to counter this risk?


  > Many FOSS maintainers live a ramen lifestyle. If someone either A. wanted
  > a zero day exploit, or B. wanted a virus to be ignored, they might be able
  > to pay the maintainer enough to violate ethics. Is there a way to
  > incentivize maintainers enough to counter this risk?

Weirdly, people living on ramen lifestyles are often the most difficult to corrupt with money. There’s a reason they aren’t using their intelligence to trade financial instruments or writing programs to do it for them.

The most vulnerable to corruption are often those with middle-class lifestyles who are living above their means and stretched to make ends meet. They often value the appearance of a comfortable lifestyle, and once you start playing golf with Alice, drinking fine wines with Bob, and horseback riding with Carol, you are in a deep financial hole.

Worse, it’s really all about the social aspects for such people, so the idea of a tight fiscal diet to regain control of their finances is anathema to them. They can’t suffer the shame of having to admit to their social circle that they don’t belong.

It’s easy for authorities to target those running up debts.

The irony is, sometimes everyone in the same social circle are all in over their head. They’re all suffering from a kind of impostor syndrome, each of them thinks that everyone else can afford the Suburban in the driveway and the jet-ski in the garage, and that they’re the only one in trouble. In reality they’re all in a Red Queen’s Race.


Three basic strategies:

1. Rewards: Provide good rewards for honest maintainers. Pay them out of government grants or get private funds to pay them. Give maintainers respect/status, community, and money. Tie the security of a product to this funding process. Rewards for no independently discovered remote exploits for X months, etc. Rewards for independent users finding and disclosing exploits.

2. Punishments: Intentional inclusion of security holes should be treated as a criminal act. FOSS maintainers who break the trust which is placed in them should be viewed as untrustworthy and anti-social. Have very clear red lines and very clear consequences. Pass laws which make it illegal for any actor , including the US government to petition a vendor to include security holes and backdoors.

3. Technical restraints: Have a two-person rule for commits. Open code reviews and cryptographically attestable append only revision systems with signed commits. Forbid coding styles that make it easy to obfuscate code. Fund independent code audits like the audit truecrypt project. Ensure the code which is published is the same as the code that was audited. Require deterministic builds.


Not only are AV software running privileged services in the operating system, they're also full of security holes in themselves.

I seem to recall a talk at Black Hat, but I can't seem to find it now, where someone did some basic file format fuzzing and could reliably run code in almost all of the popular AV software.

That's scary. I would also target them if I was a black hat or a three letter agency (which basically amounts to the same in this context).





Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: