What makes you think the COBOL systems are secure?
-
-
Replying to @theconfigurator
Oh, I am not saying that I'm saying that ancient turtles or new turtles, it's turtles all the way down
2 replies 19 retweets 541 likes -
Replying to @IanColdwater
And yet that's not a good argument for spending millions on supporting those barely functional systems.
10 replies 0 retweets 19 likes -
Replying to @theconfigurator @IanColdwater
Some of them were stringently tested by the government in the 80s. There used to be standards for computer security designed by military. That kind of standardization and testing just doesn't tend to happen anymore except for a very few niche companies.
2 replies 3 retweets 105 likes -
Modern computer programming is too much of a moving target. And, in the name of speed, we sacrifice a lot of security-first principles. https://en.m.wikipedia.org/wiki/Meltdown_(security_vulnerability) … for example. Compare to AS/400 architecture, where CPU are designed less efficiently in order to be secure.
3 replies 4 retweets 101 likes -
AS/400 isn't a CPU architecture though, it uses machine independent bytecode (like Java, Android dex, LLVM IR in iOS apps, and other similar modern versions). The actual CPUs used by AS/400 have been POWER for a while and certainly are vulnerable to Spectre subsets.
3 replies 0 retweets 4 likes -
By the way, z/OS and friends are lacking many modern security mitigations. I wrote a CTF for z/OS USS that was a trivial stack overflow, which would've instantly been caught by stack cookies on any modern system, and made harder to exploit by ASLR.
1 reply 0 retweets 5 likes -
As far as I can tell, any idea that all that big iron stuff is "secure" is a bunch of wishful thinking. Nobody is auditing those systems from the POV of modern exploitation because they're so niche and proprietary, so nobody is pumping out the CVEs. It's security by obscurity.
1 reply 0 retweets 6 likes -
Security thru obscurity might be a fair assessment. I don't trust software design for big iron to be secure, but I had read a whitepaper ages ago describing how AS/400 was designed for extremely high reliability and to discourage low-level side-channel attacks. Can't find it now
1 reply 0 retweets 1 like -
Nobody *knew* about modern side channel attacks back then. Any security claims from old systems are unlikely to hold up to modern scrutiny (and unlikely to apply to modern hardware for those platforms; everyone is doing the same stuff). Now reliability, yeah, IBM does that well.
2 replies 0 retweets 5 likes
But really, there's just no way to design a modern multi-user system without side channels. It's just not possible due to complexity, and if you actually seriously tried you would absolutely destroy performance (and still have a bunch). Big iron isn't and never was an exception.
-
-
There's a fascinating story of the Multics team evaluating how important fixing side channel attacks (altho a bit different than modern ones) really was in s complex, multiuser system. Worth a read - http://Multicians.org/timing-chn.html
1 reply 0 retweets 1 like -
That story closely mirrors my own conclusions years ago that any shared resource is a side channel (down to specific ideas, like the scheduler). I'm glad people were thinking about this back then. Too bad Intel didn't :-)
1 reply 0 retweets 2 likes - Show replies
New conversation -
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.