Live data from Hacker News

We all dodged a bullet

xeiaso.net

221–230 of 498 posts

Re: We all dodged a bullet

#221
post #76

>Saved by procrastination! Seriously, this is one of my key survival mechanisms. By the time I became system administrator for a small services company, I had learned to let other people beta test things. We ran Microsoft Office 2000 for 12 years, and saved soooo many upgrade headaches. We had a decade without the need to retrain. That, and like other have said... never clicking links in emails.

Not in the "npm ecosystem". You're hopelessly behind there if you haven't updated in the last 54 seconds.

Well in this case it makes sense to update fast isn't it?

Re: We all dodged a bullet

#222

Is this not a good use case for AI in your email client (local-only to avoid more opportunities for data to leak)? Have the client-embedded AI view the email to determine if it contains a link to a purported service. Remotely verify if the service URL domain is valid, by comparing to the domains known for that service If unknown, show the user a suspected phishing message. This will occasionally give a false positive…

No, the solution to a security problem is not to radically increase the vulnerable attack surface.

Re: We all dodged a bullet

#223

"Batteries included" ecosystems are the ultimate defense against the dark arts. Your F100 first party vendor might get it wrong every now and then, but they have so much more to lose than a random 3rd party asshole who decides to deploy malicious packages. The worst thing I can recall from the enterprisey ecosystems is the log4j exploit, which was easily one of the most attended to security problems I am aware of. Ev…

Heartbleed? Solarwinds? Spectre/Meltdown? Stuxnet? Eternal Blue? CVE-2008-0166 (debian predictable private keys)?

Re: We all dodged a bullet

#224

Besides the ecosystem issues, for the phishing part, I'll repost what I responded somewhere in the other related post, for awareness --- I figure you aren't about to get fooled by phishing anytime soon, but based on some of your remarks and remarks of others, a PSA: TRUSTING YOUR OWN SENSES to "check" that a domain is right, or an email is right, or the wording has some urgency or whatever is BOUND TO FAIL often enou…

Here's the actual root cause of the issue:

1- As a professional, installing free dependencies to save on working time.

There's no such thing as a free lunch, you can't have your cake and eat it too that is, download dependencies that solve your problems, without paying, without ads, without propaganda (for example to lure you into maintaining such projects for THE CAUSE), without vendor lockin or without malware.

It's really silly to want to pile up mountains of super secure technology like webauthn, when the solution is just to stop downloading random code from the internet.

Re: We all dodged a bullet

#225
post #111

Earlier quoted context omitted.

yea, just look at the state of many C projects. it's rather clearly worse in practice in aggregate. should it be higher friction than npm? probably yes. a permissions system would inherently add a bit (leftpad includes 27 libraries which require permissions "internet" and "sudo", add? [y/N]) which would help a bit I think. but I'm personally more optimistic about structured code and review signing, e.g. like cargo-cr…

C has a lot of characteristics beyond simple lack of a standard automatic package manager that complicate the situation. The more interesting comparison to me is, for example, my experience on C# projects that do and do not use NuGet. Or even the overall C# ecosystem before and after NuGet got popular. Because then you're getting closer to just comparing life with and without a package manager, without all the extra…

when I was doing C# pre-nuget we had an utterly absurd amount of libraries that nobody had checked and nobody ever upgraded. so... yeah I think it applies there too, at least from my experience.

I do agree that C is an especially-bad case for additional reasons though, yeah.

Re: We all dodged a bullet

#226

It seems to me that having an email client that simply disables all the links in the email is probably a good idea. Or maybe, there should be explicit white-listing of domains that are allowed to be hyperlinks.

And who would control that whitelist? How would it be any different than the domain system or PKI CA system we have now?

Do you think there would be the time to properly review applications to get on the whitelist?

Re: We all dodged a bullet

#227

Earlier quoted context omitted.

I think people rip on EDR and security when 1. They haven’t had it explained why it does what it does or 2. It is process for process sake. To wit: I have an open ticket right now from an automated code review tool that flagged a potential vulnerability. I and two other seniors have confirmed that it is a false alarm so I asked for permission to ignore it by clicking the ignore button in a separate security ticket. T…

This sounds sensible for the “ops person”? It might not be sensible for the organization as a whole, but there’s no way to determine that conclusively, without going over thousands of different possibilities, edge cases, etc.

What about this sounds sensible?

I have already documented, in writing, in multiple places, that the automated software has raised a false alarm, as well as providing a piece of code demonstrating that the alert was wrong. They are asking me to document it in an additional place that I don't have access to, presumably for perceived security reasons? We already accept that my reasoning around the false alarm is valid, they just have buried a simple resolution beneath completely stupid process. You are going to get false alarms, if it takes months to deal with a single one, the alarm system is going to get ignored, or bypassed. I have a variety of conflicting demands on my attention.

At the same time, when we came under a coordinated DDOS attack from what was likely a political actor, security didn't notice the millions of requests coming from a country that we have never had a single customer in. Our dev team brought it to their attention where they, again, slowed everything down by insisting on taking part in the mitigation, even though they couldn't figure out how to give themselves permission to access basic things like our logging system. We had to devote one of our on calls to walking them through submitting access tickets, a process presumably put in place by a security team.

I know what good security looks like, and I respect it. Many people have to deal with bad security on a regular basis, and they should not be shamed for correctly pointing out that it is terrible.

Re: We all dodged a bullet

#228

Earlier quoted context omitted.

Totally agreed, and I'm surprised this idea hasn't become more mainstream yet. If a package wants to access the filesystem, shell, OS API's, sockets, etc., those should be permissions you have to explicitly grant in your code.

It's harder than it looks. I wrote an essay exploring why here: https://blog.plan99.net/why-not-capability-languages-a8e6cbd...

tbh none of that sounds particularly bad, nor do I think capabilities are necessary (but obviously useful).

we could literally just take Go and categorize on "imports risky package" and we'd have a better situation than we have now, and it would encourage library design that isolates those risky accesses so people don't worry about them being used. even that much should have been table stakes over a decade ago.

and like:

>No language has such an object or such interfaces in its standard library, and in fact “god objects” are viewed as violating good object oriented design.

sure they do. that's dependency injection, and you'd probably delegate it to a dependency injector (your god object) that resolves permissions. plus go already has an object for it that's passed almost everywhere: context.

perfect isn't necessary. what we have now very nearly everywhere is the most extreme example of "yolo", almost anything would be an improvement.

Re: We all dodged a bullet

#230

>Saved by procrastination! Seriously, this is one of my key survival mechanisms. By the time I became system administrator for a small services company, I had learned to let other people beta test things. We ran Microsoft Office 2000 for 12 years, and saved soooo many upgrade headaches. We had a decade without the need to retrain. That, and like other have said... never clicking links in emails.

This is how I feel about my Honda, and to some extent, Kubernetes. In the former case I kept a 2006 model in good order for so long I skipped at least two (automobile) generation's worth of car-to-phone teething problems, and after years of hearing people complain about their woes I've found the experience of connecting my iphone to my '23 car pretty hassle-free. In the latter, I am finally moving a bunch of workloads out of EC2 after years of nudging from my higher-ups and, while it's still far from a simple matter I feel like the managed solutions in EKS and GKE have matured and greatly lessen the pain of migrating to K8S. I can only imagine what I would have gotten bogged down with had I promptly acted on my bosses' suggestion to do this six or seven years ago. (I also feel very lucky that the people I work for let me move on these things in my own due time.)
Post reply on HN