Hacker News Reader

Comment by tptacek | Hacker News Reader

The speculative execution stuff is fascinating and a little terrifying but, for the most part, has been of little practical impact so far, at least after the first round of Meltdown/Spectre fixes.

Attacks on various hash functions are not really a thing. We've known not to use SHA-1 for over a decade, and cryptographers working in the space have started saying we may never find a viable preimage attack on MD5, let alone SHA-1. We are on pretty sound footing with hash functions; what you were doing in a competent system 10 years ago (using SHA-2) is still the right thing today.

I've been a vulnerability researcher since around 1995. I feel significantly better about security today than I have at any point in the past. We've been doing an imperfect but steady job of shutting down bug classes for decades, with the obvious and most important factor being the deprecation of insecure systems languages.

View on HN

I don't see C anywhere near being "deprecated" in general. Usage of Rust/Zig/ATS/whatever is a rounding error by comparison to C/C++, even for new projects. Anecdotally, I've been interviewing with a few startups building ambitious infrastructure-level projects, and none of them are using Rust. C/C++ is still the only game in town outside the HN bubble.

This is true, largely because no one outside the HN bubble knows Rust/Zig/ATS/whatever. Most companies and people want to get stuff done, and a new language can get in the way of that. It'll take a while for those newer languages to pick up main-stream traction, and by a while I mean a few years of pushy college grads who used it in CS 101, 202, or 303.

Don’t be so sure about that. I don’t know any C++ dev who hasn’t heard (good things) about Rust. It’s definitely well known in the systems programming community at this point. That’s different from using it in production though.

And that's precisely the point. You don't use C++ because it's the best thing since sliced bread. You use it because you want to easily use decades of optimized libraries and get a result that's highly performant without spending a long time creating wrappers in Rust (that may not even be easy to do w/ libraries that rely on a lot of templating).

A lot of C++ projects (not all!) have relatively few dependencies. I think this "decades of optimized libraries" is a bit hyperbole.

Besides, libraries that were optimized for HW 20-30 years ago don't age all that well and are far from optimal these days. They also tend to still have a ton of bugs.

Now, I'm not saying there aren't cases where you really need to build on legacy library base. Merely that it's a bit rare case.

Libraries that are 20-30 years old and that people still use today are generally in continuous development over that time period, often with the same team (in a ship-of-Theseus sense). That means that they have been optimized for today's hardware for about 20 years worth of todays.

Now there are cases where libraries have ossified and there is room for a new library to come and eat their cake (look at ripgrep for an example), but there are also a lot of cases where they are going to be very hard to beat (a lot of boost is in this area, I believe, and there are many other examples in specialized domains).

boost fills more of a role that standard libraries play in other languages (think go).

And tooling.

Mixed language development experience in Java and .NET IDEs, UI frameworks, game engines and GPGPU shaders.

If your definition of "safe language" is "Rust/Zig/ATS/whatever", our premises aren't compatible, because I am talking about things like Java and Python. In the 1990s and early 2000s, we were still building application code in C/C++.

Hmm, I had in mind the phrase “insecure systems languages”, but I don’t want to get into a boring debate about what “systems languages” or “systems programming” mean...

It's at least as much my fault as yours, since I said "systems language" as a shorthand for C/C++, not to describe the problem domain, and it's true that the modern zero-cost-abstraction memory-safe languages that can displace the last of the C/C++ code are very new. We'll be out of the era of C/C++ when a mainstream browser is written in one of them.

As I understand it, Firefox now has substantial parts written in Rust, Mozilla's own language. Also, unless the OS and drivers are written in a memory-safe language as well, that castle is to a degree built on sand.

From a security standpoint, it really depends on your threat model.

But when it comes to software reliability, you rarely if ever should be worrying about kernel or driver bugs.

Given the above, writing your code using a memory safe language is still a huge net benefit.

> But when it comes to software reliability, you rarely if ever should be worrying about kernel or driver bugs.

Not quite sure what you mean. For an application developer, yeah, you don't need to worry.

In general... If I had a dime just for all various types of kernel memory read/write vulnerabilities due to kernel bugs and bad drivers, I'd have a lot of dimes.

> Also, unless the OS and drivers are written in a memory-safe language as well, that castle is to a degree built on sand.

You have to start from somewhere. There's Rust. I'd like to see some more language (and tooling) competition with systems that can prove functionality at compile time in practical situations.

Not impressed with current C/C++ static analysis landscape. I've used a ton of static analysis for writing Windows kernel drivers for instance — from known tools like Microsoft's Prefast (requires a ton of annotation, sigh!) to clang. And others. And fuzzing on top.

But it still doesn't come anywhere near replacing a good pair of eyes and some hard thinking. And I'm not talking about logic bugs here, but for example concurrency and memory safety related issues. I've had plenty of "quality time" (not!) with the kernel debugger...

I'm very seriously considering to use Rust instead of C/C++ whenever I have my next Windows (or other OS) kernel mode project. Even though some consider it a bit unproven in this space. At this point, I don't feel like C/C++ is proven either...

To a bit lesser degree, same for anything that touches untrusted inputs, directly or indirectly. Even if you can sandbox it.

I do need to work around some issues with Rust. Like to learn how to minimize code size for those situations where it is a constraint. Like device firmware. However I feel that's easier than writing bulletproof C/C++ code.

Part of me would like to see .NET Native available on all levels of the stack, but with WinDev vs DevTools politics, that is unfortunately just wishful thinking.

The words "to a degree" are doing a lot of work in that sentence, given where browser RCE vulnerabilities actually appear today in code.

Kernel bugs are obviously a part of modern bugchains, but they're used to escalate privileges, and usually not to gain native code execution in the first place. The enabling code execution arises from code that doesn't need to be in C/C++ at all.

Video codec provided by Cisco is installed with every instance of Firefox. Check your plugins.

C is deprecated on Windows, where the focus is now C++ and .NET, old style C code has been made compatibile with C89's C++ subset.

Even the new Universal C runtime is written in C++ using extern "C".

On Android, C is reserved for the Linux kernel and "legacy drivers" (pre-Treble), everything else is C++ and Java/Kotlin.

On Apple OSes, C is left for the UNIX style compatibility layer, everything else is a mix of Objective-C, Swift and C++.

By the way it is either C or C++, not C/C++.

VS now ships clang, so that should improve support for C considerably.

Objective-C is C, with extensions. Swift interoperates with C, not C++.

It ships clang, because that is Microsoft's answer to C support on Windows, for those that still want to use C.

Visual C++ focus is naturally C++.

C with extensions, by definition, is not C, rather something else.

Swift interoperates with Objective-C, thus C interoperability comes for free.

IO Kit, DriverKit, Metal Shaders, LLVM make all use of C++.

> I've been a vulnerability researcher since around 1995. I feel significantly better about security today than I have at any point in the past.

Do you really feel that way considering what is internet (or other accessible networks) connected today compared to 1995?

Personally I feel the opposite (although I haven't been in the game as long) because of a lot of critical infrastructure is getting connected without a lot of security. A lot of surveillance cameras, door stations, networks that in 1995 would be localized failures are now national or global. People find open, password-less VNC into control panels for powerplants just by scanning the internet. Equifax, Turkeys MERNIS and on and on and on.

I don't get the sentiment that things are getting better in this area.

The security is definitely better than in the 90s, for what I've heard. The impact of an attack is however greater. You can literally shut down an entire country today, something you could not do back then.

Documented state-level kinetic computer security attacks go back a lot further than you think they do.

Is there prior art before alleged sabotage leading to pipeline explosion in 1982? [1]

Zetter's Countdown to Zero Day points to that with skepticism and also talks about Kosovo as one of earliest cases, as does Sandworm.

Do you think this is roughly correct?

[1] https://en.m.wikipedia.org/wiki/At_the_Abyss

I'm thinking about Kosovo.

Yeah, that's what I meant. The security might be better, but the attack surface and attack impact has grown a lot faster than than the overall security.

I'm sorry, but how do you literally shut down a country? Hyperbole much?

Hack the power grid or core network/telecom infrastructure.

See also: suspected Russian attacks on Estonia related to the a statue being taken down

https://en.wikipedia.org/wiki/2007_cyberattacks_on_Estonia

I suppose if I point out a government hit by ransomware and forced to run with pen and paper just last year[1], an attack on a nuclear power plant which could have been targetted at power generation[2], an attack taking down 1/5th of the world's ocean freight and a company with enough annual revenue to be in the top 100 countries by GDP[3], or a classic software bug taking out power to 45 million people in the USA for two weeks[4], you're just going to claim those aren't important because they didn't "literally" shut down every operation in an entire country, or weren't deliberate attacks trying to do that, and therefore they aren't evidence that it could happen?

[1] https://nunatsiaq.com/stories/article/government-of-nunavut-...

[2] https://en.wikipedia.org/wiki/Stuxnet#Iran_as_a_target

[3] https://www.forbes.com/sites/leemathews/2017/08/16/notpetya-...

[4] https://en.wikipedia.org/wiki/Northeast_blackout_of_2003

From my point of view, the proliferation of so many new classes of network connected devices has offset much of the gains in better practices. With enough systems being designed, the odds of a single system being both incompetently designed and widely deployed approaches unity.

I think I'll call this the "lightbulb effect" since in 1995 the lightbulbs in everyone's home were secure against all RCE vulnerabilities, while in 2020, this is no longer true.

There was a related blog post from 2016 about a guy who managed to hack his hotel's "smart" lights/curtains/etc system. Unfortunately the images no longer work, but they're not essential anyway: https://mjg59.dreamwidth.org/40505.html

This is a reason not to buy lightbulbs with Internet connections, but not a good reason to despair about the state of overall software and hardware security.

How many people (even very computer savvy) expected their somewhat standard keyboard to contain firmware that can support keylogging? https://www.blackhat.com/presentations/bh-usa-09/CHEN/BHUSA0...

Do you know for sure your mouse is safe from this kind of thing? What about your monitor? Even things like sticks of memory and case fans have little controllers now to do some kind of programmable RGB lighting; everything is getting filled with relatively small amounts of computing power for no good reason, and it seems to be an accelerating trend.

This seems to be another example of something theoretically possible that an actuary would tell you to ignore.

Maybe, but there are online storea full of the stuff.

Reply on news.ycombinator.com