Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The six dumbest ideas in computer security (2005)

ranum.com

Post reply on HN
Print view View original

161–170 of 216 posts

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

#161

Post by Nevermark »

dexterdog wrote: post #155
causi wrote: post #150

Earlier quoted context omitted.

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.

Hmmm. Not if the firing notice was triggered by Dave from a suspicious executable in his email.

Although the idea of tightening up security practices by having some sociopathic employee tricking colleagues into publicly firing themselves by malware does make me feel a little ill.

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

#162

Post by superkuh »

mb7733 wrote: post #44
superkuh wrote: post #41

Back in 2005 the idea that you shouldn't run every bit of executable code sent to you was drilled into people. Nowadays you can't use a commercial/institutional websites without doing the modern equivalent of opening random email attachments.

But the client side code in a web-app is run within the browser sandbox, which is not equivalent to running a random exe... Unless you meant something else?

Speculative execution, sandbox exploits, etc, etc. I thought everyone (myself included) stopped believing in the power of VMs/containers/sandboxes to protect you when all that happened (and kept happening). And it's just getting worse as the JS engine(s) get access to more and more bare metal features and become a true OS in more than just spirit.

Thus all the crazy insistence on CA TLS in modern web protocols like HTTP/3 which can't even establish an connection without CA based TLS hand-holding.

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

#163

Post by hnfong »

foooobaba wrote: post #151
bombolo wrote: post #122

Earlier quoted context omitted.

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…

What do we do in practice?

- Personally audit all the 392 library dependencies in our project to make sure they don't do anything dumb?

- Ask the intern to write a non-dumb logger (and the other 392 deps) from scratch?

- Don't use dependencies and write bare metal assembler? (JDK, libc, OS kernels are dependencies and do introduce a steady stream of CVEs)

- Give up on doing anything complicated and congratulate myself at being able to write a simple echo service by implementing the whole TCP/IP stack on bare metal?

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

#164

Post by npteljes »

What I think happened is that with computing, humanity began to build a new world, a Different World that's not like the other, old world outside. But since humans were building it, it became just like that. It has the same buildup, the same issues, the same dumbness as the original, real world.

#1: Default permit: people don't like to spend energy, especially not upfront. Integrating "Permit by default" systems is much faster than setting them up with proper authentication, authorization and access rights. Permit default just works, starts quickly, and works fast.

#2: Enumerating badness: you mean, like how we name every single strain of viruses? So now we enumerate computer badness too.

#3: Penetrate and patch: very similar to how our laws work, I think. There are people who create injustises, and later the legal code is upgraded to handle that. Again, reactive, like in #1.

#4: Hacking is cool - well, other criminals are cool too, like pirates and maffiosos, and so on. People are drawn to power.

#5: Educating users: someone has to, doesn't they, if they haven't learnt the thing by themselves? You can't make everyone go away if they are dumb, if you need them.

#6: Action is Better Than Inaction: This one, I think, imitates business. There's a lot of ways to make money in business, and being there early is one of them.

That said, I really enjoyed the article. Permit by default is especially dumb, it was really funny when mongo installed itself with no password and listen on public IP, default port. And how long it took them to patch that. And how that haven't burned the public goodwill! So maybe these things are not really dumb after all?

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

#165

Post by nine_k »

tptacek wrote: 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…

I suppose the idea of denying by default (#1, #2) and the idea of defense in depth (mentioned at the end) aged well enough.

I'm not sure about educating users. It's obviously not going to be a bulletproof solution. But not educating users at all also does not seem right either: it's hard for a person to care about stuff they have no idea about.

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

#166

Post by bigbillheck »

causi wrote: post #150
bluedino wrote: post #147

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."

> Have you tried threats and public humiliation?

Looks like we've found a seventh.

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

#168

Post by namaria »

Spooky23 wrote: post #152
bluedino wrote: post #147

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 an…

"The spot where we intend to fight must not be made known; for then the enemy will have to prepare against a possible attack at several different points; (...) If he sends reinforcements everywhere, he will everywhere be weak."

Sun Tzu, Art of War. I know, cheesy to compare network security with warfare. But, I've learned that big shinny stack of tools is a red flag. If there is no threat model and focused hardening, you're not doing security, you're doing compliance.

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

#169

Post by eduction »

tptacek wrote: 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…

> It hasn't aged well.

You’re wrong, it’s aged quite well.

Just take as one important set of examples the new mobile operating systems since this piece was published. Even the most thoughtfully designed and locked down (even with hardware, various uses of encryption etc) continue to have vulnerabilities at the base layer year after year. Bug hunting looks every year more and more like just an expensive sport for condescending security experts who think little about the broader context in which they operate. As much as we all appreciate the whack a mole.

Where there has been genuine security improvement is where we’ve taken the structural, locked down approach advocated here (see also djb’s paper about qmail security). iOS and Android apps (particularly the former) seem genuinely more secure than most desktop apps because they are structured to have very limited permissions from day one. The app environments on those systems looks like they were designed with many of the principles from this post expressly in mind.

The lessons for the OS layer seem obvious. Qubes and in particular Joanna’s post about “Qubes Air” point in one very promising direction.

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

#170

Post by rfoo »

eduction wrote: post #169
tptacek wrote: 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…

> It hasn't aged well. You’re wrong, it’s aged quite well. Just take as one important set of examples the new mobile operating systems since this piece was published. Even the most thoughtfully designed and locked down (even with hardware, various uses of encryption etc) continue to have vulnerabilities at the base layer year after year. Bug hunting looks every year more and more like just an expensive sport for cond…

> (see also djb’s paper about qmail security)

You mean the guy who refused to fix an integer overflow bug, claiming it isn't practical to exploit then 64-bit really happened then years later suddenly the fine guys at Qualys decided to have fun? [1] Sure, he is a crypto expert and we're all grateful for his work on curve25519, salsa/chacha, nacl, djbsort, etc (and I'm sure I missed a lot). This does not mean he is an expert on weird machine.

[1] https://www.qualys.com/2020/05/19/cve-2005-1513/remote-code-...

Post reply on HN