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.
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.
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.
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.
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.
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.
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).
Mixed language development experience in Java and .NET IDEs, UI frameworks, game engines and GPGPU shaders.
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++.
Objective-C is C, with extensions. Swift interoperates with C, not 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++.
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.
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://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
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.
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.
The team that fielded inquiries from security researchers and etc were STILL fighting fights with engineering executives whose first response when they saw something that showed a problem in their code from a researcher ... was to go running to the lawyers and talk about lawsuits.
In the meantime some engineers recognize the increased need for better security practices but there were NO new resources allocated to actually make time to do such things. Everything was lip service (if there even was any) but no time, and then later reactive to issues.
In terms of what I saw in a practical manner. There was a shockingly high rate of "we saw this security bug before" re-introduced right after it was fixed. You could almost bank on it happening. In the meantime you'd watch security related bug fixes pushed from one version to the next to the next ...
Security is economic. There's a cost/benefit to attack, and to defend.
A good way to measure how secure we actually are is to observe the rate of cryptocurrency theft. How many people do you know with crypto? How many people do you know who have had their computers hacked and crypto stolen? That's how secure you are.
In some cases, sure. In other cases (e.g. if you're a nation declaring war on the US) you kind of have to assume basically-unlimited cryptanalysis resources and the willingness to prioritize their use to attack your crypto.
Is there a name for the discipline of "cybersecurity doctrine as pertains to protecting against unlimited-strength attacks"? Sort of the crypto equivalent of the Airforce One doctrine, of trying to ensure that an individual survives ICBMs aimed directly at their best-predicted location (with the predictive capacity of a state actor.)
What about ransomware + spyware where you just lost account numbers and IP?
Just stop. There is zero reason to be reckless with infosec and IT infrastructure.
Sometimes things will exist outside of your control but that’s a long shot away from “whatever, it won’t happen to me”.
"whatever it won't happen to me" isn't my point, but okay. I'm not advocating for recklessness or apathy toward infosec / IT. I'm not trying to tell anyone how to live their lives, and explicitly I'm not saying what a company should do. I'm just trying to convey how I view MY risk from a target probability perspective vs the loss it would incur, and thus how I decide to trust some HW/SW
Not sure why you're trying to strawman me here, no need to be hostile
Sure, they might not be digging out your bank account number, but since the cost to the attacker of compromising your machine might be nothing more than a few hundred packets, they'll try anyway.
It isn't perfect, but it works for me.
If you're a bank in a metropolis, you get a sophisticated vault. If you're a business you get an alarm system to protect your inventory. If you're a farmer and it's the less expensive farm equipment, you might not even lock the barn/shed.
If you expect state level adversaries, you probably need state level resources, planning, and mitigations. If you're jane/joe schmoe citizen, don't give out your passwords or click on unknown binaries, and be wary of people asking you for SMS codes in IMs. Scale appropriately for the threat you think you'll face, and as much buffer as you think you can stomach.
Has any real ones been found and confirmed?
I remember one being mentioned a couple of years ago or so by one researcher but last I can remember it was not confirmed and IIRC other researchers were voicing their doubt about it.
For some reason my head was shortcutting "attack" to mean "infect".
Thorrez in sibling comment mentions BadBIOS which is probably the one I thought about.
(Also, I realize that my brain thinks 2013 is "a couple of years ago". On a personal level that is possibly even more scary :-/ )
Not much.
We actually know how to deal with most of the things you mentioned. There are simple CPU cores that don't have speculative execution problems. It is possible to achieve memory safety. Formally proven OS kernels exist. Physical security is largely understood and can be made very difficult to compromise.
Why don't we have all this as routine? Because security theater is cheaper than actual security. The value of 'cheaper' here is very broad and includes avoiding all of the costs that emerge with robust security including opportunity costs.
Good security is getting rarer all the time, and therefore expensive; I think a lot of people would be interested in having a small truly secure system (say, for storing your cryptocurrency keys), and as I wrote, I sincerely don't know where to practically begin with this.
Is it commercially available? Concretely speaking, what can I buy, and what software should I run on it?
But the gains they made have surely outweighed any current hit? Also I haven’t perceived that much of a hit (although I’m not in the industry): are they selling more CPUs? AMD have an opportunity, but I haven’t seen that translated into sales to hyperscalers or consumers (beyond what they were achieving anyway).
Same as Microsoft knowingly for decades chose functionality before security - with the cooperation of plenty of customers that knew better.
For example, I’m reasonably sure there are weaknesses in my gaming pc but I don’t do banking or other more secure things on it. There’s little motivation to target an attack or burn (use) an exploit to get access to this pc for an attacker and the defenses I have defend against most spray and pray attacks.
There is no reason to think that anything has changed with the explosion of security consultants and firms.
If you are doing anything national security related, you should really just boil your security thinking down to thinking about the remotest possibility something could happen, and then multiply that x10, and then apply your mitigation.
Well, I can only remember one time I've had any of my personal devices compromised in 25 years of heavy computing, and it windows XP pre-SP3. So yeah, quite a bit of faith seems to be warranted, even if the stream of flaws makes it seem like it shouldn't be
IE is made by a trillion dollar company but you can still find tons of security issues with IE.
There are, and in those, good code can be written. They're the exception. Source: worked there for 7 years.
I wonder if you could do a kind of power over ethernet thing, where you increase the system's power draw in a precise manner that gets a signal outside the Faraday cage, since presumably your power will come from an external cable.
A typical way to do this is to use TLS, verify certificates, and have a password for the client.
https://en.wikipedia.org/wiki/Fallacies_of_distributed_compu...
(But of course these fallacies are so well known exactly because programmers have proven their inability to reliably internalize them...)
I worked for 7 years so I know how the software sausage is made. The answer is most definitely "no", and I'm frankly surprised now that the internet works at all.
This is why I rant about C, even though I seldom touch it.
The "experts" that sell our infrastructure have proven multiple times they aren't able to deliver.
3 from 5 exploits are memory corruption bugs.
Even as a fairly tech savvy guy I wouldn't actually know how to make a truly secure computing environment short of putting the whole thing in a silent Faraday cage and having metal detecting scans going in and out.