Ah! - does this explain the weirdly specific message that came out from GCHQ last week? https://www.telegraph.co.uk/news/2020/01/12/gchq-warns-not-u...
Not sure if related. Support ended, so it's a good recommendation whether some new attack is revealed or not. Especially when new patch for a newer version can reveal unpatched issues in older versions. What do you think is oddly-specific about it?
Cryptic Rumblings Ahead of First 2020 Patch Tuesday
91–96 of 96 posts
Re: Cryptic Rumblings Ahead of First 2020 Patch Tuesday
#92Earlier quoted context omitted.
People will just go around. I find it hard to resist making a comment in those movies set in New York City where a character has a steel jacketed door and a million locks but I bet the wall is cheap gypsum board and studs on 18 inch centers. You could steal a lot of stuff around a door without even compromising the building structure. You just need the right sheet rock knife and a quiet hallway. Someone told me about…
> Where it's more likely to help is that you'll find crashing bugs you may have missed, and you save some face by not having particularly naive bugs in your code. That doesn't sound right at all. Systems with atrocious security are more likely to be compromised than systems with good but imperfect security. Attackers do not have infinite resources.
I took the proposal on the table to mean that we systematically harden infrastructure code. If that's what we're doing then a rising tide will lift all boats. Except for the people who fall behind on upgrades. There is a period of chaos where your prediction will play out over and over, but eventually there's a new equilibrium where it's just different rocks to look under. Then people get bored again and they fall behind on upgrades, and now every time new functionality is added to the formal system, by definition people using the old version aren't getting that protection, so you'd look there first.
I think the critical question would be is how quickly does a formal system reach homeostasis? If the rate of bugs (or maybe you call them features?) is negligible after a brief flurry of initial activity, then most of my argument collapses in a divide by zero error.
As to priorities, I don't think penetration and debugging are fundamentally that different. And by that I mean, there's some fuzzy math you do regarding cost (to you) of checking a thing times the value of having that information. Yes, that means a ton of cheap scenarios will be tested very early. But ultimately, how valuable is breaking into a boring system? It's definitely not zero, because you've created another resource for yourself.
Doesn't code that runs on a lot of systems get far more attention than code that runs on a few? Wasn't that part of why OS X got away with fewer viruses? Not because it was profoundly harder to hack, but simply because fewer people cared?
Re: Cryptic Rumblings Ahead of First 2020 Patch Tuesday
#93Earlier quoted context omitted.
Note that even if you prove correctness of code, there still might be bugs in the compiler, so you will have to prove the compiler. Then there could be bugs in the modules / DLLs / dependencies in the OS, so more proving needs to be done. Then there might be bugs in the CPU. So it's not so easy. T hen there are things which you simply can't prove, eg. In crypto the code may be correct, yet it may still leak some side…
The goal isn’t to deliver a provably correct system - that’s effectively impossible. But if core OS features or APIs (like the network stack) can be written in a theorem-proving language, huge benefits can be realized — the attack surface can be vastly reduced.
Re: Cryptic Rumblings Ahead of First 2020 Patch Tuesday
#94Earlier quoted context omitted.
When they feel like, most of the time however they hold back vunerablities so they can exploit them for their own purposes. Modern NSA is more Black Hat than white Hat sadly
>When they feel like, most of the time however they hold back vunerablities so they can exploit them for their own purposes. You have no idea if that's true or not. It's probably true, but neither of us have the information required to assert our opinions on the matter as fact.
Re: Cryptic Rumblings Ahead of First 2020 Patch Tuesday
#95Earlier quoted context omitted.
> Where it's more likely to help is that you'll find crashing bugs you may have missed, and you save some face by not having particularly naive bugs in your code. That doesn't sound right at all. Systems with atrocious security are more likely to be compromised than systems with good but imperfect security. Attackers do not have infinite resources.
Which also doesn't sound right. I took the proposal on the table to mean that we systematically harden infrastructure code. If that's what we're doing then a rising tide will lift all boats. Except for the people who fall behind on upgrades. There is a period of chaos where your prediction will play out over and over, but eventually there's a new equilibrium where it's just different rocks to look under. Then people…
When we take steps to eliminate classes of vulnerabilities, well, those vulnerabilities stop being a problem, and we're all more secure. For example, code written in Java or C# is immune from the buffer-overflow attacks, and use-after-free attacks, that continue to plague C code.
There was no counterweight built into this. Security was simply improved.
> Then people get bored again and they fall behind on upgrades, and now every time new functionality is added to the formal system, by definition people using the old version aren't getting that protection, so you'd look there first.
Failure to update packages causes security issues, yes. That doesn't mean that security improvements don't, well, improve security, overall. They absolutely do.
> If the rate of bugs (or maybe you call them features?) is negligible after a brief flurry of initial activity, then most of my argument collapses in a divide by zero error.
If they're using formal methods, they won't be adding bugs. (Discounting side-channel issues.)
I believe it's pretty unusual to see a company make non-verified changes to a codebase originally derived through formal methods. If they care about formal verification, they'll probably stick with it as they make changes.
> how valuable is breaking into a boring system? It's definitely not zero, because you've created another resource for yourself.
Sure - botnets.
> Doesn't code that runs on a lot of systems get far more attention than code that runs on a few?
Of course, but I'm not seeing what you're getting at here.
Re: Cryptic Rumblings Ahead of First 2020 Patch Tuesday
#96It's a shame that mathematically proving correctness of code, even for extremely important code , is never done. I wonder how many lines of code in crypt32.dll. Is it on the order of 7500 lines? If Microsoft spent a few man-years mathematically proving the correctness of that code, they could have the saved the world about 10,000 man-years. Windows has a user base of 1 billion[1]. A ballpark figure for proving the co…
The inertia and complacency of existing code is enormous, MS and other affluent vendors have been watching vulns in their codebases bubble up for decades and their customers tolerate it.
Big MS customers buy into it deeply: companies won't hire security professionals as CSOs who would ban insecure "industry standard" setups such as org wide AD domains and MS office attachments that malware most often spreads through.