Comment by Animats | Hacker News Reader

Comment by Animats | Hacker News Reader

Parent Full thread

I'm getting worried. I've been harping on the Maersk downtime lately. The ports of the largest shipping company in the world have been shut down for two days by a cyber attack. Trucks can't unload or load at many of the world's ports, including the main container ports of LA, NYC, and Rotterdam. They're going to be down tomorrow, too. Maybe partial operation by Friday.[1] Maersk even lost phone and email systems. One of the few good sources of info has been somebody at the Port Authority of New York and New Jersey who sends out alerts to truckers.

It's a distributed outage. The usual forms of disaster preparation involve geographic dispersal. That doesn't work against this threat. Few companies are as physically dispersed as Maersk, which has major facilities in 61 countries. It didn't help.

What happens when someone figures out how to take over Windows Update or the Intel Management Engine or Ubuntu Update?

[1] http://btt.paalerts.com/recentmessages.aspx

Finally, after two days, Maersk is starting to come back on line. They've managed to get a status page up.[1] Some of their biggest and most automated ports are still completely down. Maasvlakte II (Rotterdam) is completely down; their main Rotterdam port is down except for ship loading.

Some US ports are up with manual operation; Port Elizabeth (NJ) is loading and unloading ships and trains, but not trucks. Los Angeles is totally down.

The Asian ports are mostly up.

The shipping industry is very worried about this.[2]

[1] http://www.maersk.com/~/media/20170629-operational-update/20... [2] http://splash247.com/back-future-maersk-wake-petya-attack/

Thanks, I'd been looking for recovery info. This is scary, in a way that I hope might clarify to governments and intelligence agencies just what kind of damage these issues do.

And thanks for that. Your earlier HN comments were the first notice I had of that, and I agree, it's absolutely massive. First thought through my head was David Korowicz's "Global Supply Chain Cross-Contagion", though I think it might take a somewhat harder kick.

http://www.feasta.org/2012/06/17/trade-off-financial-system-...

Have you posted/blogged on this anywhere, because I'd like to see your general thoughts on this.

Another thought is that these attacks are far more epidemiological than military. That is, the spread amongst susceptible hosts, via chains of transmission, and can be controlled or limited through what are fundamentally epidemiological mechanisms: identifying reservoirs, patients zero and defence penetration, treatment by isolation, innoculation, monitoring, host-separation, and host diversity.

Similar argument apply to many of the memetic and human-based communications attacks which have been escallating of late.

A friend has pointed out that any communications network -- physical or logical -- ultimately becomes attractive as a mode of attack or subversion. The 1970s and 1980s vision of the Vast Interconnected World, perpetuated through the 1990s through the PR and advertising of companies such as IBM, AOL, AT&T (1-800-YOU-WILL), Microsoft, Google, Facebook, ..., was that this would be a better an peacefully interconnected world.

Clay Shirky has pointed out that when you connect more people ... there are more people to argue with. And who will try to scam, or subvert, or attack, or profit by, or gain political power through, communications, information, financial, or media networks. The bigger the system, the bigger the draw.

And ... yet we still don't prepare for this.

I'd very much like to see the EU, US, India, and China call for a public post mortem from Maersk. And to step up the game on computer security. Because this is, as you've said, deadly serious.

The first step would be to stop using C (and any other memory-unsafe language). The vast majority of these problems come about by memory corruption tricking the computer into executing attacker-delivered code (or ROP gadgets).

Yes there will be other security flaws like missing access checks, etc. But none are so pervasive nor so devastating as out-of-bounds read/write. If C arrays were bounds-checked by default then the majority (literally) of exploits would be rendered void immediately. The Rust borrow checker, Swift ARC, or GCs would eliminate use-after-free. Combined that would drastically reduce all available attack surface.

The second step is to assign a separate identity to every piece of code, rather than running everything as the current user. Unless it has been initiated by a user action there is no reason for malware to even have write access to your files (or system files for that matter). The idea that any ol random bit of code that manages to execute should be just as trusted as the user is crazytown. IMHM macOS SIP is a good step in that direction, enforcing read-only access to /System and most of /usr.

The third step is to have pervasive copy-on-write, including in all filesystems by default. If your system does get pwned it should be a trivial matter of booting to a read-only recovery mode and rolling back to a known-good state.

The fourth step is to have more interlocks enforced by the system that cannot be overridden. For example there might be a legitimate reason to truncate shadow copies but why should anyone with admin rights be allowed to do so from a normal login session? That's just stupid. (For those unaware, malware now routinely disables Windows' volume shadow copy and nukes the existing copies to stop you from rolling your files back). Stuff like that should require rebooting into single-user mode or recovery mode.

There's always a lot of resistance to the idea of dropping C. Before you go replying with a counter-argument I urge you to stop and think seriously. We've been pushing secure coding standards as an industry for many years now. Everyone is well aware of the risks. We have tools like Address Sanitizer and Undefined Behavior Sanitizer. We have lots of static analysis tools. We have tools like valgrind. And yet... the exploits keep on coming. Despite the thousands upon thousands of years of effort poured into fixing it, we still routinely have new out-of-bounds and use-after-free exploits in critical C code. Even experienced developers get bitten by signed integer overflow and other forms of undefined behavior... and most C code is not being written by experienced careful developers. Embedded code is even worse. If you read the source behind your car's ECU you'd probably never drive again.

It is time to admit the truth: programming languages should be memory-safe by default. Period. Whatever the cost it is worth paying.

> The first step would be to stop using C (and any other memory-unsafe language). The vast majority of these problems come about by memory corruption tricking the computer into executing attacker-delivered code (or ROP gadgets).

Seriously. People have been saying this for decades now, and warning of future disasters in using memory unsafe languages. The warning signs were all there in early worms and viruses, but still we haven't changed the languages we use or the access control systems that leave gaping wide holes in our computer systems. The chickens are coming home to roost, and everyone will feel the economic impact of this short sightedness!

Ada has been around long enough, but it was a little painful when I was using it a few years back despite all the great safety benefits. Thank god for Rust. I sincerely hope it, or something like Idris really takes off.

Well, it's always a tradeof, isn't it? Manual memory management gives you greater freedom and performance, with added risks. That being said, performance is what you want when it comes to low level layers that other layers have to rely on - e.g. You don't want your net stack be dragged down by a slow TCP/IP implementation.

Now you have rust. No excuses.

When all the rust libraries are in my package manager and when rust is as simple to write as C let me know, until then it's laughable that you think it's a replacement.

To replace C rustc needs to be a drop in replacement for gcc, not a whole platform on it's own as it is now with cargo.

> when rust is as simple to write as C let me know

Good C is not simple to write, that's the whole point.

> To replace C rustc needs to be a drop in replacement for gcc, not a whole platform on it's own as it is now with cargo.

The argument here is about dropping C. You can't replace C without paying some kind of a price.

> Good C is not simple to write, that's the whole point.

Seriously. It's like we're all riding unicycles on tightropes to get around, and someone invents sidewalks and bridges, and everyone is like, "well if you just learned to ride your unicycle properly and worked tirelessly on your balance, you wouldn't have this problem of 'falling to your death' or 'recklessly endangering other people'".

The reality distortion field around systems programming is strong.

But men, those sidewalks and bridges are expensive ! And all my drivers know the shortcuts on ropes and will have to learn the whole map again if we use the road. Plus our unicycle have wheels shapes for ropes, not side roads, it would take us a lot of time and resource to do that. The whole industry is stuck in that case, and the market has a huge inertia you know.

You just can't use sidewalks and bridges right now instead of ropes. It's just not pragmatic.

> The argument here is about dropping C. You can't replace C without paying some kind of a price.

The thing is that rust cannot replace C right now. The only stable ABI that rust has is the C one, which removes most of the benefits of using rust.

If rust would be memory safe or concurrency safe rust would be a valid option. Unfortunately it is not. But fast and safe options do exist.

Here the problem is the OS and it's lack of security, not the language.

> That being said, performance is what you want when it comes to low level layers that other layers have to rely on - e.g. You don't want your net stack be dragged down by a slow TCP/IP implementation.

What you don't want, is a whole economy disrupted by a poor technical decision. Abstract technical goals like "performance" are not valuable goals in themselves.

Before you go replying with a counter-argument I urge you to stop and think seriously.

I have thought about these things for a long time, and arrived at the exact opposite conclusion: had such levels of security been there since the beginning of computing, there would be no jailbreaks, rooting, homebrew, or any real freedom. Everything would be so locked down and unbreakable that there would be no "possibility to disobey", and that is a far more terrifying alternative.

A world in which there is no crime is one where everyone has already been strongly coerced into submission and every aspect of their lives closely monitored and controlled. Ultimately, humans are imperfect and that's where all of these exploits and vulnerabilities come from. If we attempt to eradicate them, by essentially removing imperfection, we will literally be taking the humanity out of life. Is that really the (cyber-)world you want to live in, or move towards?

Whatever the cost it is worth paying.

I see this continuing insecurity as consolation that we still have some freedom left, but positions like yours --- increasingly popular, it seems --- are strongly reminiscent of the "war on terrorism" and its associated repugnance, because it is really the "war on cyberterrorism".

As the classic saying goes, "Those who give up freedom for security deserve neither."

I agree. The real danger is software monoculture. We need many diverse systems with very different attack surfaces. Less standardization. That's the way nature survives. We just need to learn the lesson.

Nature also has things like immune systems, but you get into very sketchy legal territory there. Our legal system have not caught up with this new interconnected reality.

Oh, and nature very frequently suffers all kinds of systemic collapse. Nature isn't immune to this.

Still kicking after 3 billion years.

Your comment is very bizarre. Securing software is in no way comparable to giving up freedom.

This. We've known how to secure computers from this kind of nonsense for decades and there have been hundreds of massively expensive attacks over the years. Every time a new "biggest attack in history" happened, I thought "maybe now the cost of repair has finally exceeded the cost of killing C".

Nope. I've been wrong every time. The psychological cost of abandoning backward compatibility is still considered unthinkably expensive, regardless of the economic cost of repair after an attack. The bad guys will continue to win until we change this mindset.

I'm a C programmer and i agree with this - C is fundamentally flawed from security viewpoint. However security isn't everything about the language. The reason we don't switch to "C alternatives" is that they all have flaws and don't replace the flexibility and versatility of C/C++. E.g draconian type systems(Ada) or pedantic enforcement of memory safety(Rust). When programming in your language is painful, no one will switch to it, and C/C++ will continue to dominate and be the basis of most software stacks/operating systems/runtimes. An analogy is: why are you using a car which is unsafe,expensive, polluting and prone to road accidents, instead of safe, reliable, cheaper and environmentally friendly cargo tricycle?

If I could wave a magic wand I'd have the C standards committee:

1. Add safe arrays to the next version of the standard.

These arrays would work much like C arrays do, but taking a reference or passing to another function would pass an array_ref type rather than decaying to a pointer. Under the covers an array_ref would be a (size_t, address). Taking a reference to an element in the middle of an array would get the correct size of the reference.

The default mode would be to bounds-check accesses to array_ref, aborting on failure. Since the array_ref knows its size it would be easy to check the index and return an error code if you prefer not to abort ("if (i >= sizeof some_array_param)").

2. Make signed integer math trap on overflow and add wrapping variants (similar to Swift's &-prefixed versions of operators). For some projects this would be too disruptive but compilers would undoubtedly offer options to disable it. But the fact that this existed at all would immediately start pushing people to adopt it for the same reason people like to adopt -Weverything or -Wall.

2b. Add generic functions to check for potential overflow so we can have an officially blessed way to say "if x + y > INT_MAX" with no undefined behavior. This is so easy to accidentally get wrong without any obvious indication that you've introduced undefined behavior.

3. Some blessed reference counting library and/or types. If C had something to say about memory management other than "you're on your own" it would be a big boon to eliminating dangling pointers and use-after-free. I recognize there are many contexts where this isn't appropriate (e.g. embedded that statically allocates all memory at startup) but a lot of C code could adopt a stdlib-provided reference counting system if it existed. ARC has proven you can get everything except cycle detection without too much overhead.

I'm sure people could quibble with the exact solutions I've proposed and there may be other things I've missed, but I'd really like to see the standard admit that C has a really nasty legacy and do something about it.

An analogy is: why are you using a car which is unsafe,expensive, polluting and prone to road accidents, instead of safe, reliable, cheaper and environmentally friendly cargo tricycle?

Or a motorcycle, which is even more unsafe --- but "hella fun", in the words of a friend. I'd rather drive, being in control, and take the risk than be forced to ride in a safe, boring, highly-regulated self-driving car.

You aren't just putting yourself at risk by driving, you're putting other people at risk too.

this may apply to a motorcycle you ride for fun (hobby project?) but when I program for a living my top priority is to best/fastest solve the problem at hand, not to have fun.

Thats would be assembler and demoscene.

Google chrome os!!!

Add on your comment about c, it's also a major problem with Windows. It's tragically so easy to attack windows systems with endless patching and discovery of vulnerabilities. The vast majority of companies could get by with their clients (the people who click on these stupid attachments with the infected pictures or word docs or web links) if they were given google chrome os laptops. google chrome os laptops would hugely reduce vulnerability problems for majority of end users.

You seem to have given this a lot of thought. So serious question - why don't you create a secure operating system for governments and big corporates? You would easily get the funding and likely an insane amount of revenue.

The second step is to assign a separate identity to every piece of code

Cool story, but now you will need a time machine to go back 50-odd years and tell them this. And to build that time machine you will need C.

Reply on news.ycombinator.com