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

201–210 of 216 posts

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

#201

Post by edrxty »

pookha wrote: post #148
edrxty wrote: post #6

Looking back on that era, the hate towards hackers feels really misplaced. Yeah, at the time it was more local and more dominated by people doing it for the lolz but we kinda owe them a debt of gratitude. If they hadn't gotten everyone to stop being lazy about security we'd be in a very different place now, surrounded by rouge states and agencies launching hyper sophisticated attacks on infrastructure and data. That…

It wasn't misplaced...There were some horrific pieces of "hacker" software that were floating around in 05. Wasn't uncommon for a disgruntled employee to load malware onto a company's network and bring down operations for weeks. Case in point, douchebag loaded a maleware into this small financial company's network that I wound up working for. The virus infected the boot sector and forced the company to do low level f…

In fairness, there aren't a whole lot of ways left to run around corrupting the boot sectors on an entire network. Given current politics I'd rather have everyone learn how to enforce user access control in '05 rather than in '23.

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

#202

Post by mb7733 »

superkuh wrote: post #162
mb7733 wrote: post #44

Earlier quoted context omitted.

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

The fact that exploits exist doesn't imply that using sandboxes is equivalent to running untrusted code directly.

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

#203

Post by rfoo »

zefix wrote: post #177
arp242 wrote: post #143

Earlier quoted context omitted.

> Yep, it’s worth repeating. I don't know; I haven't really seen most of these things in the wild for a long time. For "#4) Hacking is Cool" the zeitgeist has moved in the exact opposite direction with "white hat", bug bounties, etc. I think that section in particular is a pretty outdated view of things. "#6) Action is Better Than Inaction" is probably the only one that still broadly applies today, and is actually a…

Honestly #4 applies as much as ever. - At least in most regards. The thing is: The 'security researchers' which I've had contact with focus mostly on hacking and memory corruption attacks. The thing is: This is a solved problem by now! And yet, instead of teaching students to avoid the horrible tools, which cause those problems, they keep on teaching how to penetrate and fix. It's maddening.

Please tell me you have already thrown Firefox, Chrome, old Microsoft Edge and whatever browser out of window and are posting to HN with you rewritten-in-Rust lynx.

Not being able to rewrite the world or convincing people to stop using memory unsafe languages is entirely unrelated to what security researchers do.

I'd love to stop having to build complicated lifetime model in my mind to figure out whether there are hidden code paths for a UAF, but at the same time this is the best thing I can do to secure what we have today, now it's on you to rewrite the world.

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

#204

Post by zefix »

rfoo wrote: post #203
zefix wrote: post #177

Earlier quoted context omitted.

Honestly #4 applies as much as ever. - At least in most regards. The thing is: The 'security researchers' which I've had contact with focus mostly on hacking and memory corruption attacks. The thing is: This is a solved problem by now! And yet, instead of teaching students to avoid the horrible tools, which cause those problems, they keep on teaching how to penetrate and fix. It's maddening.

Please tell me you have already thrown Firefox, Chrome, old Microsoft Edge and whatever browser out of window and are posting to HN with you rewritten-in-Rust lynx. Not being able to rewrite the world or convincing people to stop using memory unsafe languages is entirely unrelated to what security researchers do. I'd love to stop having to build complicated lifetime model in my mind to figure out whether there are hi…

No.

We need to stop compromising.

Yes, there is a lot of old code.

No, I can't do it all on my own.

But we can do it as a profession. Refuse to take jobs, nag managers, refuse to by hardware that only supports C, etc.

If construction was as ridiculous our fiels, we'd still use asbestos.

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

#205

Post by randomcarbloke »

tptacek wrote: post #46
ufmace wrote: post #10

I wonder how well we all think this article has aged? "Penetrate and Patch" is supposedly dumb. But what do we practically do with that? We've seen in the last decade or so a lot of long-lived software everyone thought was secure get caught with massive security bugs. Well, once some software you depend on has infact been found to have a bug, what's there to do but patch it? If some software has never had a bug found…

1. Default deny is one of the oldest best practices in security engineering; it barely needed saying in 1995 (but Cheswick & Bellovin said exactly that in Firewalls & Internet Security). 2. "Enumerating badness" is simultaneously an attempt to connect vulnerability research to antivirus (security practitioners have had contempt, mostly justified, for AV since the late 1980s) and an endorsement of the heuristic detect…

4/6 and it hasn't aged well?

1 might be ubiquitous even in 2005 but it's 2022 and this was the page that was shared, obviously it was worth Ranum stating...

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

#206

Post by bombolo »

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…

So? The article doesn't mention "security against specific memory attacks". It's meant to be generic security, and I was pointing out that your comment was restricting the field too much.

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

#207

Post by bombolo »

mixmastamyk wrote: post #7
lmm wrote: post #4

Not convinced these are the dumbest (none of them is quite as dumb as requiring special characters in passwords, for example, and I'm not sure the fourth is dumb at all), or that they're six ideas. The first two are the same, and the third one is a special case of the same thing.

What’s the deal with special chars? A site made me use one today.

Special but not special, don't you dare use a non ASCII character or the whole backend explodes.

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

#208

Post by eduction »

tptacek wrote: post #200
eduction wrote: post #197

Earlier quoted context omitted.

Hi, that’s an interesting assertion but not actually accurate. It is vaguely related to the truth; djb acknowledges that qmail failed to partition in the way he advocates in the paper but says it survived without serious security issues for other reasons: “ I failed to place any of the qmail code into untrusted pris- ons. Bugs anywhere in the code could have been security holes. The way that qmail survived this failu…

It didn't "survive" in that manner: it wasn't LP64 clean, and had memory corruption vulnerabilities.

You described something the qmail paper said and I corrected you. If the paper is inaccurate that’s orthogonal.

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

#209

Post by SAI_Peregrinus »

nine_k wrote: post #165
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.

The better way is to make the secure path the easy path. You don't have to educate users to do something that makes their life harder, you can educate them in an easier way to do what they want. That's far more likely to stick.

Usability is a security issue; at the ultimate extreme a DoS attack is just creating a very poor user experience.

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

#210

Post by tptacek »

eduction wrote: post #208
tptacek wrote: post #200

Earlier quoted context omitted.

It didn't "survive" in that manner: it wasn't LP64 clean, and had memory corruption vulnerabilities.

You described something the qmail paper said and I corrected you. If the paper is inaccurate that’s orthogonal.

You're also incorrect about the paper.

Really, the whole argument you're making --- the reason we're talking about Bernstein in the first place --- is broken. Bernstein himself would probably not agree with the take you're trying to derive from the relationship between his work and "enumerating badness".

Post reply on HN