Live data from Hacker News

The six dumbest ideas in computer security (2005)

ranum.com

151–160 of 216 posts

Re: The six dumbest ideas in computer security (2005)

#151

Earlier quoted context omitted.

With respect to this example, I think he is saying it would be better if we were using memory safe languages, rather than trying to come up with these sorts of mitigations (which is enumerating the bad). Of course it’s probably not possible in every scenario because we’ve been doing it badly for so long, but I think the principle still holds.

Remember the log4j thing? And yet java is memory safe.

This has nothing to do with ASLR and stack canaries.. Log4jshell wasn’t a buffer overflow exploit, it was the result of yet another dumb idea, adding remote jndi loading capability into the logging framework.

You can assume any input to your program will be manipulated by an attacker. This implies if you use a non memory safe language you’ll need to make sure there is no way the user can input enough data to overflow your buffer, which will corrupt your memory, and get it right 100% of the time. If you’re building a logging framework it’s extremely likely people will be logging some sort of information from the outside, so not a great idea to execute it as code. Similarly for sql injections, if you simply use prepared statements you remove a whole class of problems. Knowing an attacker will probably inject some garbage into the input of your program, and assuming user input is malicious, is a basic principle you can use to design better systems. I believe this is what the author meant by his statement.

Re: The six dumbest ideas in computer security (2005)

#152

This describes the security industry as a whole. We had a user click an email and get phished. We tried training the users with tools like KnowBe4, banners above the emails that say things like THIS IS AN OUTSIDE EMAIL BE VERY CAREFUL WHEN CLICKING LINKS. Didn't help. The email was a very generic looking "Kindly view the attached invoice" The attached invoice was a PDF file The link went to some suspicious looking do…

Several years ago, I worked on an incident response for an incident that was detected and stopped.

Tl;dr, a targeted phishing email was the catalyst for the whole thing. The various systems that detect these thing effectively blocked it ~97/100 times. One click was all it took. The user who clicked had a bad feeling and used a blame-free and convenient reporting mechanism to report it.

That doesn’t mean that tools and training are useless. As a defender in any context, defense has to be multilayered and flexible as circumstances change. In IT, sports or warfare, it’s the same process or funnel.

The scenario you described likely would have been detected by an EDR tool, or by log analysis if there was a process to do that. Declaring “shitshow” is accepting a bad outcome. Unfortunately as the value of compromising a company has gone up, the opponents have leveled up, and defenders need to as well.

Re: The six dumbest ideas in computer security (2005)

#153
post #15

Related: The Six Dumbest Ideas in Computer Security (2005) - https://news.ycombinator.com/item?id=28068725 - Aug 2021 (21 comments) The Six Dumbest Ideas in Computer Security (2005) - https://news.ycombinator.com/item?id=14369342 - May 2017 (6 comments) The Six Dumbest Ideas in Computer Security - https://news.ycombinator.com/item?id=12483067 - Sept 2016 (11 comments) The Six Dumbest Ideas in Computer Security - http…

There's something ironic about there being exactly six past posts about it.

Except there are at least 12 previous posts of this article. It was only posted once the year it came out, but it had a real renaissance about 6 years ago for some reason.

Re: The six dumbest ideas in computer security (2005)

#154
post #62
post #54

Earlier quoted context omitted.

> my iPhone is more secure than linux for the same reason The phrase "more secure" doesn't mean anything, I wish it wasn't used. One needs to talk about the threat model(s) you care about and how a particular solution addresses them (or not). Any given solution can be both more secure and less secure than an alternative, depending on what threat models you care about. Which may well be different than the threat model…

> The phrase "more secure" doesn't mean anything Fair point. I'll elaborate: The linux (UNIX) security model is designed to protect users from other (potentially malicious) users on the same computer. The system as a whole is designed such that a malicious (or incompetent) user can't make the system as a whole stop working. The system is more important than any particular users' data. Software is assumed to be correc…

> 3. Malicious software is everywhere. Every time I install a package some stranger wrote on npm or Cargo, I implicitly give it full access to all my data and my entire network.

This particular case wouldn't really be prevented by an Android/iOS-type security model, I think? That package will be part of the program you're writing, and chances are that program requires more than the bare-minimum access.

That said, it's not extraordinarily difficult to lock this down, if you really want to. Docker is common, but more traditional tools work as well (e.g. running your program as its own user, maybe in a chroot), and/or using cgroups directly.

This applies even more with things like VSCode extensions, which typically run inside the VSCode process, and without filesystem access VSCode is pretty useless.

Re: The six dumbest ideas in computer security (2005)

#155
post #150

This describes the security industry as a whole. We had a user click an email and get phished. We tried training the users with tools like KnowBe4, banners above the emails that say things like THIS IS AN OUTSIDE EMAIL BE VERY CAREFUL WHEN CLICKING LINKS. Didn't help. The email was a very generic looking "Kindly view the attached invoice" The attached invoice was a PDF file The link went to some suspicious looking do…

Have you tried threats and public humiliation? "ATTN ALL employees: Dave Smith ignored security training and was phished into installing malware. He is now fired because he was an idiot."

I think there are a number of departments that will help you join Dave in his new-found freedom from employment if you send that.

Re: The six dumbest ideas in computer security (2005)

#156
post #24
post #12

> "We can't stop the occasional problem" - yes, you can. Would you travel on commercial airliners if you thought that the aviation industry took this approach with your life? I didn't think so. This person has a fundamentally mistaken idea of how airliners and, therefore, security systems as a whole work. Yes, airliners have the occasional problem. That's why they have: * checklists and inspections, to catch them bef…

> "We can't stop the occasional problem" - yes, you can. All those tools (checklists, redundancies, etc) exist to increase the reliability rate. And to stop the occasional problem (ground crew forgets to refuel plane) from turning into a disaster[1]. I might be overly generous, but thats my read of the author's intent. That just like in the airline industry, we have tools to stop occasional problems from turning into…

> And to stop the occasional problem (ground crew forgets to refuel plane) from turning into a disaster[1]. > [1] https://en.wikipedia.org/wiki/Gimli_Glider

While I agree with your general point I have to disagree the particulars here.

The ground crew did not refuel the plane, because the pilots did not request refuelling. There was no-one "forgetting" to refuel, least of all the ground crew.

The pilots did not request fuel because they thought they have enough. And they thought they have enough because they made a unit conversion error in their calculations. (there are even more layers and twists and turns to this cheese lasagne, but no one "forgot" to refuel that is for sure.)

Re: The six dumbest ideas in computer security (2005)

#157
post #62
post #54

Earlier quoted context omitted.

> my iPhone is more secure than linux for the same reason The phrase "more secure" doesn't mean anything, I wish it wasn't used. One needs to talk about the threat model(s) you care about and how a particular solution addresses them (or not). Any given solution can be both more secure and less secure than an alternative, depending on what threat models you care about. Which may well be different than the threat model…

> The phrase "more secure" doesn't mean anything Fair point. I'll elaborate: The linux (UNIX) security model is designed to protect users from other (potentially malicious) users on the same computer. The system as a whole is designed such that a malicious (or incompetent) user can't make the system as a whole stop working. The system is more important than any particular users' data. Software is assumed to be correc…

The landscape of security switched from the computer to the user.

As user you need to become root in a way or another to install a system program or something that affects the system as a whole. And you are aware that you are doing something that affects the system as a whole. The security was meant for multiuser environments, the computers were shared in a way or another.

But what matters now about that computer (specially when you are the single user of it) is your user, your data, your credentials, your network access, etc, all that you as user (and app you run) can access, or modify. Viruses and malware in general used to be system threats, but it is enough to be user threats now.

Things are moving to containerized in a way or another applications (docker, snaps, whatever do iOS and Android with that, etc), with limited access to your data, credentials and so on.

Re: The six dumbest ideas in computer security (2005)

#158
post #89
post #26

A reminder that a big part of the subtext of this piece is a reactionary movement against vulnerability research that Ranum was at the vanguard of. Along with Schneier, Ranum spent a lot of energy railing against people who found and exploited vulnerabilities (as you can see from items #2, #3, and #4). It hasn't aged well. I'm not sure there's anything true on this list that is, in 2023, interesting; maybe you could…

What was the argument against vuln research? The 'Penetrate & Patch' bit makes it sound it's something like 'this is pointless because the proper way to fix this stuff is better design and other things are a waste of time and effort'.

This predated a lot of the responsible-disclosure culture that exists now, so there was a lot of “find vuln, post right away for the credits” going on. Couple that with a lot of tool research that was important but also felt very grey-hat, and it was easy to feel like much of the “vulnerability research” community were like a group of scientists working on making cancer airborne “for research purposes”. I admit to having felt that way then, too.

Fortunately a lot of that has subsided. The focus on responsible disclosure while still holding companies accountable, the great security research being done by projects like Talos or Project Zero, and the consistent flow of new open-source blue-team tooling has really helped balance the scales (if they were ever unbalanced).

Post reply on HN