This shouldn't have happened: A vulnerability postmortem • Hacker News Board

Re: This shouldn't have happened: A vulnerability postmortem

#381

Post by nicoburns » Thu, Dec 02, 2021, 10:01 AM UTC

foobiekr wrote: post #343

saagarjha wrote: post #307

Earlier quoted context omitted.

In C you can just use code execution to grab the passwords before they get salted…

One is the whole database. I am very aware of code execution attacks and persistence around them. C has a class of failures that are not present in most other languages that are in current use, my point is that it really only solves part of the problem. From a security perspective, the 90% issue is the poor quality of developers in whatever language you choose.

I think the difference is in the difficulty in preventing the bugs. I'd be very surprised if our codebase at work contained SQL injection bugs. We use a library that protects against them by default, and all code gets reviewed by a senior developer. SQL injection is easy to prevent with a simple code review process.

Subtle issues with undefined behaviour, buffer overflows, etc in C are much trickier and frequently catch out even highly experienced programmers. Even with high quality developers your C program is unlikely to be secure.

Re: This shouldn't have happened: A vulnerability postmortem

#382

Post by kobebrookskC3 » Thu, Dec 02, 2021, 10:03 AM UTC

lelanthran wrote: post #377

kobebrookskC3 wrote: post #375

Earlier quoted context omitted.

your code probably isn't worth attacking

> your code probably isn't worth attacking Maybe, maybe not. What bar do you set for "this product is worth attacking"? Because the product owners and the product users definitely thought that their product was valuable[1]. [1]The products in question were 1) Payment acquirer and processor, and 2) Munitions control software.

a product can be valuable without being worth attacking, like something that only runs on trusted inputs. the bar for software "worth attacking" for me is that there are people who are paid mainly to find exploits on it, and not just incidentally as a product of development.

Re: This shouldn't have happened: A vulnerability postmortem

#383

Post by oblio » Thu, Dec 02, 2021, 10:04 AM UTC

renewiltord wrote: post #355

nineteen999 wrote: post #300

Earlier quoted context omitted.

No issue with the first sentence of your message at all, but... > No offense to the many bright and capable people who have worked hard on the C/C++ language, tools, compilers, libraries, kernels, etc over the years, but we will someday look back on it as asbestos and wonder why we kept at it for so damn long. We won't wonder at all. We will understand that those people are the ONLY ones that stepped up to the task o…

Lmao. Absolute perfection. Software that exists has way more value.

Not when that software and the ecosystem around it, which are entrenched, actively fight against change.

If you think that's not true, C++ programmers, raise your hand if you were ever working on/contributing to a C program and you proposed C++ as a safer/better language and got shot down.

So even C++ is facing the same kind of challenges now faced by newer programming languages.

Re: This shouldn't have happened: A vulnerability postmortem

#384

Post by flohofwoe » Thu, Dec 02, 2021, 10:05 AM UTC

pjmlp wrote: post #342

nineteen999 wrote: post #300

Earlier quoted context omitted.

No issue with the first sentence of your message at all, but... > No offense to the many bright and capable people who have worked hard on the C/C++ language, tools, compilers, libraries, kernels, etc over the years, but we will someday look back on it as asbestos and wonder why we kept at it for so damn long. We won't wonder at all. We will understand that those people are the ONLY ones that stepped up to the task o…

> We will wonder why with all the millions of lines of C/C++ reference code available to be perused and then rewritten in Rust, Pascal, C#, Zig or Nim, and the vociferousness of their advocates, why that didn't happen in a reasonable timeframe. Easy, every single time .NET team does some advances into that direction, it gets sabotaged by WinDev and their C++ love. XNA vs DirectXTK, .NET vs COM/WinRT,... Windows could…

That was simply because the alternatives to Win32 had various serious regressions, be it usability, features, bloat, or other things that are important in one way or other to the people who stick with Win32.

More secure languages and APIs can only win if they are both easier to use and offer the same features.

Re: This shouldn't have happened: A vulnerability postmortem

#385

Post by oblio » Thu, Dec 02, 2021, 10:05 AM UTC

Woodi wrote: post #312

titzer wrote: post #275

Earlier quoted context omitted.

The whole post is a giant blinking red sign that says (or should say) "Fuzzing is a horribly ineffective workaround for a treacherous language." No offense to the many bright and capable people who have worked hard on the C/C++ language, tools, compilers, libraries, kernels, etc over the years, but we will someday look back on it as asbestos and wonder why we kept at it for so damn long .

> but we will someday look back on it as asbestos and wonder why we kept at it for so damn long. Maybe. But there is good reason for C dominance - it's low level and close to systems as in "syscalls and stuff". And we need that level of systems control, not only for max performance but also for not loosing what is available in hw and os. Asm is the other option to have full functionality :) Maybe it's just case of av…

> C actually should be improved and not fucked up into forced disuse...

It can't, it won't, it isn't.

The last major update has C99 and even that was minor from a security point of view.

For better or worse, it's frozen.

Re: This shouldn't have happened: A vulnerability postmortem

#386

Post by scatters » Thu, Dec 02, 2021, 10:06 AM UTC

Kalium wrote: post #244

benjaminjackman wrote: post #240

Earlier quoted context omitted.

Genuinely curious what the use case(s) of reading from uninitialized are. Performance?

It was used as a source of randomness. Someone blindly fixing a "bug" as reported by a linter famously resulted in a major vulnerability in Debian: https://www.debian.org/security/2008/dsa-1571

This is incorrect.

If they had simply removed the offending line (or, indeed, set a preprocessor flag that was provided explicitly for that purpose) it would have been fine. The problem was that they also removed a similar looking line that was the path providing actual randomness.

Re: This shouldn't have happened: A vulnerability postmortem

#387

Post by pjmlp » Thu, Dec 02, 2021, 10:08 AM UTC

ptx wrote: post #369

blub wrote: post #357

Earlier quoted context omitted.

Before I ditched Windows a couple of years ago, I was able to experience first hand how bloated and slow was the software that Microsoft rewrote in C#, so I kind of understand why such rewrites were being sabotaged. If by some minor miracle a C# or Java GUI app is not slow, then it will use a ton of memory. A whole OS of such apps would be a nightmare.

The new modern/UWP apps in Windows 10, like the calculator and start menu, are written in C++, aren't they? They manage to be horrendously slow and bloated without C#, so maybe C# isn't the problem.

They are, UWP is basically another take on what was being discussed before .NET as COM evolution, and Longhorn's failure has given them the wind to pursue it as Windows foundation.

So since Vista all major Windows APIs are COM based, not always surfaced to .NET, and we are expected to just go through books like ".NET and COM: The Complete Interoperability Guide" and do the needful ourselves.

WinRT as introduced in Windows 8 was then the full reboot, with .NET metadata taking over TLB files (COM type libraries) and introducing a new base interface IInspectable.

So the long term vision pursued by Synofsky, was that .NET Native and C++/CX would take over with COM fully replacing .NET.

Naturally it all failed down during the borked execution, and now you still have devs pushing for C++/WinRT, the C++/CX replacement, with ATL like tooling as "modern". Maybe it is modern given the tools that they are used at WinDev, I guess.

Ars even has a nice article how this reboot took place,

https://arstechnica.com/features/2012/10/windows-8-and-winrt...

Re: This shouldn't have happened: A vulnerability postmortem

#388

Post by lelanthran » Thu, Dec 02, 2021, 10:09 AM UTC

kobebrookskC3 wrote: post #382

lelanthran wrote: post #377

Earlier quoted context omitted.

> your code probably isn't worth attacking Maybe, maybe not. What bar do you set for "this product is worth attacking"? Because the product owners and the product users definitely thought that their product was valuable[1]. [1]The products in question were 1) Payment acquirer and processor, and 2) Munitions control software.

a product can be valuable without being worth attacking, like something that only runs on trusted inputs. the bar for software "worth attacking" for me is that there are people who are paid mainly to find exploits on it, and not just incidentally as a product of development.

> a product can be valuable without being worth attacking, like something that only runs on trusted inputs. the bar for software "worth attacking" for me is that there are people who are paid to find exploits on it.

I'm in agreement, but then we get back to the fact that memory safety may not be a compelling argument to use a new language.

After all, most products aren't "worth attacking" until they are large and successful enough, thus reinforcing the decision not to rewrite a product in a new language. This means that memory safety alone is not a compelling argument for switching languages.

Re: This shouldn't have happened: A vulnerability postmortem

#389

Post by flohofwoe » Thu, Dec 02, 2021, 10:10 AM UTC

ptx wrote: post #369

blub wrote: post #357

Earlier quoted context omitted.

Before I ditched Windows a couple of years ago, I was able to experience first hand how bloated and slow was the software that Microsoft rewrote in C#, so I kind of understand why such rewrites were being sabotaged. If by some minor miracle a C# or Java GUI app is not slow, then it will use a ton of memory. A whole OS of such apps would be a nightmare.

The new modern/UWP apps in Windows 10, like the calculator and start menu, are written in C++, aren't they? They manage to be horrendously slow and bloated without C#, so maybe C# isn't the problem.

It's quite simple really. Bad programmers (or good programmers in bad environments) are able to write slow code in any language, and the current Windows Desktop team seems to be an example of that.

Re: This shouldn't have happened: A vulnerability postmortem

#390

Post by pjmlp » Thu, Dec 02, 2021, 10:12 AM UTC

flohofwoe wrote: post #384

pjmlp wrote: post #342

Earlier quoted context omitted.

> We will wonder why with all the millions of lines of C/C++ reference code available to be perused and then rewritten in Rust, Pascal, C#, Zig or Nim, and the vociferousness of their advocates, why that didn't happen in a reasonable timeframe. Easy, every single time .NET team does some advances into that direction, it gets sabotaged by WinDev and their C++ love. XNA vs DirectXTK, .NET vs COM/WinRT,... Windows could…

That was simply because the alternatives to Win32 had various serious regressions, be it usability, features, bloat, or other things that are important in one way or other to the people who stick with Win32. More secure languages and APIs can only win if they are both easier to use and offer the same features.

As proven by mobile OSes, it is not technical features that win the game, rather railing the developers into the future, regardless of their opinion.

The problem at Microsoft is that what Office and WinDev want, drives the whole business no matter what, those "serious regressions, be it usability, features, bloat, or other things" get fixed, if one cares enough to make it happen.

Speaking which, Office now is an heavy user of JavaScript, less perfomant than .NET, because it needs to be in the cloud.

Whereas Windows, while king of the desktop, is undeniable that it lost the backend to POSIX clones even if we consider MS shops with IIS, where languages like Java and Go dominate.

Also apparently PWAs are cool now as fight against ChromeOS, which from performance point of view are much worse than those former Win32 alternatives.