Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Insecurity Industry

edwardsnowden.substack.com

Post reply on HN
Print view View original

201–210 of 386 posts

Re: The Insecurity Industry

#201

Post by michaelt »

lionkor wrote: post #178
franga2000 wrote: post #161

Earlier quoted context omitted.

The line is far less blurry than you suggest. The stats from the article say 70% of vulnerabilities come from [insert list of a few memory-wrangling mistakes here]. I'd consider any language that enables the top 70% of vulnerabilities to happen to be unsafe. Maybe a safety ranking is in order? How many CVEs from [year], weighed by severity, are impossible to happen in [language]. Obviously this idea has serious probl…

An statistical approach like that has the flaw any the most used language would always appear to be at the top of the "most unsafe". Instead, people should be schooled to write better code. Thats it. Don't let some random new employee with no certifications write safety-critical code. Don't hire people who are under qualified. Its really that easy. I have no idea, honestly, how you would introduce a use-after-free bu…

> Don't hire people who are under qualified. Its really that easy.

I understand what you're saying, but I'm not sure I agree.

For example, look at Google Chrome. They've got mountains of cash. They've got loads of people working for them, and loads of job applicants if they want more. They've got a strong business case to work on security. They've got in-house pen testers, and a bug bounty program. They've got code reviews. They can afford any static analyser on the market. They've got sandboxing. They've got open source so many eyes can spot bugs easily. They can dictate terms on requirements - if Chrome vetos a new web standard and it's as good as dead, and if Google decides plugins have got to go, they go.

And they've got 177 CVEs so far in 2021 [1] - including such greatest hits as use-after-free, buffer overflows and out-of-bounds access.

You and I think we're writing secure C++ - but if the best-resourced team in the world can't write secure C++, isn't it more likely we're just fooling ourselves?

[1] https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=chrome

Re: The Insecurity Industry

#202

Post by pjmlp »

ARandomerDude wrote: post #118
mehlmao wrote: post #90

Earlier quoted context omitted.

Private plane manufacturers went bankrupt, but more importantly, plane crashes have become incredibly rare.

True but that's the trivial case. You'll never get food poisoning if we outlaw food, never get into a car accident if we outlaw cars, ... The point is there should be a better way that just pull the plug on anything potentially unsafe.

Generally I get food poisoning when the restaurant, supermarket or producer fails to follow the health standards it is obliged by law.

And then I can sue them to death or make a report to health authorities that will act accordingly.

Re: The Insecurity Industry

#203

Post by grncdr »

kragen wrote: post #199
pjmlp wrote: post #188

"If you want to see change, you need to incentivize change. For example, if you want to see Microsoft have a heart attack, talk about the idea of defining legal liability for bad code in a commercial product. If you want to give Facebook nightmares, talk about the idea of making it legally liable for any and all leaks of our personal records that a jury can be persuaded were unnecessarily collected. Imagine how quick…

If this happens, it will be the end of open source and the indie web. Only large companies with large legal departments and serious liability insurance, and anonymous underground hackers, will be able to afford to make software public for commercial use or run a website.

How would this make running a personal website risky from a legal liability perspective?

Re: The Insecurity Industry

#204

Post by slickrick216 »

pjmlp wrote: post #188

"If you want to see change, you need to incentivize change. For example, if you want to see Microsoft have a heart attack, talk about the idea of defining legal liability for bad code in a commercial product. If you want to give Facebook nightmares, talk about the idea of making it legally liable for any and all leaks of our personal records that a jury can be persuaded were unnecessarily collected. Imagine how quick…

Yeah imagine if we make pharmaceutical manufacturers accept liability for vaccine side effects. It’s the same argument right.

Re: The Insecurity Industry

#205

Post by etripe »

zucker42 wrote: post #69
dmoy wrote: post #18

Earlier quoted context omitted.

Most of the people I went to Uni with ended up in fields where the companies are liable for bad stuff, to a certain degree. It does exist. However: * you get paid a lot less * the companies and industries move very slowly * you spend a lot more time writing long-form, some time just re-using existing stuff wholesale, and almost no time building actually new things I mean like Real Engineering fields. What we do in so…

I don't completely disagree but > you get paid a lot less Isn't that the point? That is, the argument is right now the money goes to the devs, management, and stockholders, when it rightfully should go to those people damaged by the software (or toward preventing them from being damaged). > the companies and industries move very slowly How much of this is due to liability law and how much is due to natural aspects of…

> Isn't that the point?

If the money is supposed to go towards people preventing damage, wouldn't that include devs?

> How much of this is due to liability law and how much is due to natural aspects of the relevant technology?

I can only speak from my own experience in biotech, but moving slowly was due to a lot of compliance box-ticking that didn't actually contribute a lot to either safety, reducing defect rate or meeting requirements. Conway's law applied: since bio engineers and lab techs move slowly, so did the software org.

Re: The Insecurity Industry

#206

Post by pjmlp »

native_samples wrote: post #174
forty wrote: post #171

Earlier quoted context omitted.

Which part of Android is written in java? The kernel? The drivers? The JVM ? I somehow doubt anything significant of the OS itself is written in java :)

Which parts? I'm surprised this isn't well known already. Large parts of Android are written in Java. Amongst other things: * All the UI libraries, networking APIs code. * All the system apps and services like the home screen, the keyboard, the system server, the window manager, the telephony subsystem (very important!) and so on. * Many of the system APIs including services like the alarm manager, dropbox manager, s…

Apparently the idea that Android is a Linux distribution is hard to dispel, because most rather read what is written in some random blog posts patting their backs about "Linux victory" than actually read what is going on at AOSP and Gerrit PR.

Re: The Insecurity Industry

#207

Post by aphexairlines »

kragen wrote: post #199
pjmlp wrote: post #188

"If you want to see change, you need to incentivize change. For example, if you want to see Microsoft have a heart attack, talk about the idea of defining legal liability for bad code in a commercial product. If you want to give Facebook nightmares, talk about the idea of making it legally liable for any and all leaks of our personal records that a jury can be persuaded were unnecessarily collected. Imagine how quick…

If this happens, it will be the end of open source and the indie web. Only large companies with large legal departments and serious liability insurance, and anonymous underground hackers, will be able to afford to make software public for commercial use or run a website.

That doesn't excuse providing products that easily blow up and damage the consumer when there are safe means to build the product.

Re: The Insecurity Industry

#208

Post by pjmlp »

kragen wrote: post #199
pjmlp wrote: post #188

"If you want to see change, you need to incentivize change. For example, if you want to see Microsoft have a heart attack, talk about the idea of defining legal liability for bad code in a commercial product. If you want to give Facebook nightmares, talk about the idea of making it legally liable for any and all leaks of our personal records that a jury can be persuaded were unnecessarily collected. Imagine how quick…

If this happens, it will be the end of open source and the indie web. Only large companies with large legal departments and serious liability insurance, and anonymous underground hackers, will be able to afford to make software public for commercial use or run a website.

Nope, they only need to uphold to the same standards.

The guy selling food on the street has the same liability as a restaurant.

Re: The Insecurity Industry

#209

Post by parksy »

kragen wrote: post #199
pjmlp wrote: post #188

"If you want to see change, you need to incentivize change. For example, if you want to see Microsoft have a heart attack, talk about the idea of defining legal liability for bad code in a commercial product. If you want to give Facebook nightmares, talk about the idea of making it legally liable for any and all leaks of our personal records that a jury can be persuaded were unnecessarily collected. Imagine how quick…

If this happens, it will be the end of open source and the indie web. Only large companies with large legal departments and serious liability insurance, and anonymous underground hackers, will be able to afford to make software public for commercial use or run a website.

That's one extreme extrapolation. How about, if this happens, it will be the end of commercial IP and the closed-web. Only open source with its inherent transparency and broad, distributed contributors (who would you sue? everybody at once?) and constant, real-time updates and improvements without lock-in or planned obsolescence would thrive when improved regulation gives avenues for redress and improves consumer awareness of security, as consumers flee the commercial silos in droves.

Re: The Insecurity Industry

#210

Post by KirillPanov »

quenix wrote: post #172
KirillPanov wrote: post #114

Earlier quoted context omitted.

Targeting those is for n00bs. Backdooring the modem firmware is far more useful, and reliable. Not to mention undetectable -- not only is the user unable to recompile or replace this firmware, they can't even get a checksum of it. Qualcomm's modem chips get their own private NAND flash that they can use as they please.

Realistically, how useful is compromising modem firmware if like 98% of communication done through it is encrypted at the AP level? It’s sorta like wiretapping a fiber optic cable—okay, what now?

On SoCs with an on-chip modem, the modem can write to any part of host memory it likes. No IOMMU.

On the (very) few remaining phones that use two separate chips, what do you think the odds are that the host OS is hardened against attacks originating from its own modem? That is a hideously complicated protocol spoken between the modem and the host processor. Plenty of validation+overflow footguns. Finding exploits here isn't going to get security researchers promoted, if they can find them at all. "Exploit is available only to modem manufacturer" does not engender a high CVE score.

Oh, and, just to top it off, that interface between the modem and the host processor when they aren't on the same chip is... drum roll... USB. As in, BadUSB. As in, Mr. Phone says: "wow, somebody plugged in a USB keyboard! And a USB mouse!".

But hey, the modem doesn't even need to own the CPU. It can record and exfiltrate your GPS location quite happily via LTE, all on its own. And buffer up a nearly unlimited amount of location data on that private NAND flash it has in case you're out of cell range. All while pinky-swearing that location services are definitely absolutely turned off, promise. I don't know why people believe that location-tracking is ever turned off on a phone; it's just absurd to think that.

Post reply on HN