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

241–250 of 386 posts

Re: The Insecurity Industry

#241

Post by sat0ri »

michaelt wrote: post #201
lionkor wrote: post #178

Earlier quoted context omitted.

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 r…

So many CVEs are due to their bug bounty program, hackers are incentivized to sell vulnerabilities to Google rather than exploiting them. CVEs are publicly disclosed after they are fixed, of course.

Re: The Insecurity Industry

#242

Post by x4e »

dxuh wrote: post #177

Everyone in these comments mentions C and C++ as a single word, which frankly has nothing to do with reality. C++ is a FAR safer language than C, if you wish to use it properly (which many don't). I write C++ full time at work and I also use it a lot in my free time and I rarely if ever have out of bounds accesses, use after free or any of these bullshit errors. If you use modern C++ and AdressSanitizer and don't do…

C++ can be safer but that does not mean it is safe. The fact you have out of bounds accesses, even if it is rare, is not really acceptable in a language that would like to be considered “safe”.

Re: The Insecurity Industry

#243

Post by pjmlp »

eru wrote: post #235
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…

Eh, contract law gives you all the tools you need to create liability. If you want software where the vendors are liable, you can get that today.

Indeed,

https://madeintandem.com/blog/massive-hertz-accenture-lawsui...

Re: The Insecurity Industry

#244

Post by pjmlp »

Ma8ee wrote: post #240
eru wrote: post #235

Earlier quoted context omitted.

Eh, contract law gives you all the tools you need to create liability. If you want software where the vendors are liable, you can get that today.

Oh yea, I’ll definitely win if I sue Microsoft, and being in the right will absolutely make a difference.

The litte guy isn't the only scenario,

https://madeintandem.com/blog/massive-hertz-accenture-lawsui...

Re: The Insecurity Industry

#245

Post by minusSeven »

Do people really think any of this is ever going to change? Governments don't give a shit, they time and again say they won't do something only to later do it in secret.

We should at this point accept that this isn't going to change and move ahead with the belief that your data is already hacked and is not private anymore. We should discuss more on the exact consequences of this and take actions accordingly.

Re: The Insecurity Industry

#246

Post by pjmlp »

kragen wrote: post #230
pjmlp wrote: post #208

Earlier quoted context omitted.

Nope, they only need to uphold to the same standards. The guy selling food on the street has the same liability as a restaurant.

The guy selling food on the street has liability in proportion to his profits; fifteen customers, fifteen potential food-poisoning cases. He can set his prices accordingly. Simon Tatham doesn't have any profits, but his PuTTY is installed on every developer's Windows machine. OpenSSL is installed on even more machines. How long do you think it would take your proposed regulatory regime to find that Kurt Roeckx owed s…

That is for the law makers to decide,

If someone gets run down by a bicycle that a hobby repair shop failed to fix, it doesn't matter it was done for free by a guy that learned to repair bicycles during late nights.

Re: The Insecurity Industry

#247

Post by swiley »

nine_k wrote: post #123
Hermitian909 wrote: post #112

Earlier quoted context omitted.

As a professional software engineer I'm not sure the idea of "safe" or "unsafe" programming languages is a coherent idea, or if it is then all languages are unsafe in my eyes. Yes C/C++ have more footguns than Java but there's no "hard line" in the safety differences and there are real and important things that need doing that it's not always clear can be reasonably done in another language. If you haven't, I'd encou…

Certainly there's no boundary that clearly delineates "safe" and "unsafe" languages. But certain languages (like C and C++, for instance) have built-in footguns. They were built in for various important reasons, but right now many of these reasons are not as pressing anymore. We can take something like Ada, Rust, OCaml instead, or at least use the extensive tooling that allows to statically check programs written in…

They certainly started off that way but modern static analysis can catch a lot. Plus these other languages (yes, including Rust) are all still at least partly implemented in C/C++ so you cant outright ban it.

Re: The Insecurity Industry

#248

Post by goodlinks »

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…

I always wondered if IEC61508 would ever be applied like this.

IIRC it could be interpeted as coving a range of types of harm to people and the environment that is not restricted to control systems.

https://en.wikipedia.org/wiki/IEC_61508

Re: The Insecurity Industry

#249

Post by eurg »

pjmlp wrote: post #246
kragen wrote: post #230

Earlier quoted context omitted.

The guy selling food on the street has liability in proportion to his profits; fifteen customers, fifteen potential food-poisoning cases. He can set his prices accordingly. Simon Tatham doesn't have any profits, but his PuTTY is installed on every developer's Windows machine. OpenSSL is installed on even more machines. How long do you think it would take your proposed regulatory regime to find that Kurt Roeckx owed s…

That is for the law makers to decide, If someone gets run down by a bicycle that a hobby repair shop failed to fix, it doesn't matter it was done for free by a guy that learned to repair bicycles during late nights.

The hobby repair shop can only be liable for a very small number of bikes, those they worked on. You cannot restrict the number of users of free source software, and you cannot restrict the user's risk profile. Like "good enough for an offline arcade game, but nothing else". Analogies have their limits.

But yes, lawmakers will decide, and given that they for instance try to de facto prohibit aftermarket OpenWRT installs, I have a guess how they would decide.

Re: The Insecurity Industry

#250

Post by staticassertion »

trasz wrote: post #218
roca wrote: post #192

Earlier quoted context omitted.

CHERI is far more than just an "alternative implementation of C". It includes a completely different hardware platform and replacing all your hardware can hardly be considered "cheap".

It's many orders of magnitude cheaper than replacing all your software.

You can't just adopt that hardware and get memory safety. The hardware is providing support for a capabilities model, which you then have to adopt at a software level both within your OS, compiler, and application code. This also would break C and C++ ABIs, so it's very unlikely to get adopted for a number of cases.

Further, CHERI is not enough to achieve temporal memory safety, it only provides the primitive that one could use to implement an efficient, correct tracing GC.

Perhaps most importantly, one can not use CHERI today. It is just not an option. Memory safe languages exist, and have existed for quite some time.

Pointer tagging and other approaches like CHERI are very promising. Keeping in mind of course that they double the size of pointers and have a global runtime performance cost. Less ambitious but otherwise similar mitigations are already being adopted.

Post reply on HN