General Talk

Why 30-Year-Old Computer Hacking Methods Still Work

This topic contains 1 reply, has 2 voices, and was last updated by  taku 5 years, 9 months ago.

  • Author
  • #10615


    A system is only as secure as the end user, as any grey-haired sysadmin will happily tell you. As a result, all the alphanumeric passwords in the world can’t protect a system if a user is tricked into running malware, something against which there’s very little defense—or so people think.

    Tom Scott has an interesting look at the history of basic phishing attacks, and how the common desktop hierarchical folder system enables their success. His logic is pretty good: users are always going to accidentally open viruses, which under the centralized file system used by desktop OSes, can run rampant. Not exactly news, and the fix normally involves scary and ineffective posters by the water cooler.

    Scott’s counterproposal is a little different: draw inspiration from mobile OSes, where sandboxed apps have their own storage space, and precious little ability to infect the rest of a device. Keep using hierarchical systems for trained users, but appify everyone else, and security could be much better, he posits.

    It’s not a perfect fix—Android malware is alive and well, often in the form of entirely fake apps—but it’s a neat thought about an often-forgotten part of our computing history.

  • #10616


    The sandboxing idea is pretty common (and a pretty good idea overall) but it’s got two big weaknesses:

    1) Holes in in the sandboxes. This is the problem with Oracle Java JVM and Adobe Flash player. They’re trying to keep malware from getting outside the sandbox, but they’re so badly written that for every hole plugged there are another dozen leaks sprung. Browsers then try to sandbox those, but there are holes in them too!

    Or you can say, well, just run everything in a VM. Great, except it has the same problems – it’s really the same thing. Xen hypervisor had a massive escalation bug for seven years before it was fixed.

    2) This is the biggest one – users demand convenience. And app writers demand convenience. And every convenience you give them is a hole in the security. Ideally every app would be an island on its own, unable to see anything else, completely unable to harm other things.

    Fine. Except now you want your editor app to be able to see things in your Dropbox. Okay, so you create a tunnel from Dropbox… Whoops, you’ve just created a system-wide hole. This was a huge thing with the initial Android SD-card support. Once you let any app read/write anywhere on the SD card, then all apps could steal the data of other apps that wrote anywhere on the SD card. And it’s multiplied by the first problem.

    And nobody’s going to let security win over ease of use because most users don’t give a shit about security and any barrier to ease of use will be some lost users.

    I’m all for sandboxing stuff, it’s certainly an improvement, but it’s not a panacea. An alternative is permissions, like Linux and NTFS security permissions, but again, it’s not a panacea because convenience means you have to poke holes in it. You just can’t fix the fundamental problem that users are computer ignorant and will trade their password (or retina scan) and even let you sit at their computer for a Snickers bar.

You must be logged in to reply to this topic.