Top
Best
New

Posted by saikatsg 6 hours ago

We have a year to fix security everywhere(jyn.dev)
238 points | 213 commentspage 3
jasonvorhe 2 hours ago|
> And a big fuck you to DeAlignAI, Z.ai, and everyone else who's been participating in this race to the bottom.

I'm so glad frontier level AI isn't in the hands of just the Altmans and that other cult leader who are currently live testing their products in actual conflicts in the middle east and Ukraine.

protocolture 6 hours ago||
Just like Cryptolocker, this will be the "Finding Out" phase for everyone who has been putting off best practice security.

But, lets be clear, Best Practice will save you. We can engineer assuming there are zero days in path. Go to your CTO now cap in hand and ask for overlapping controls, wafs, application monitoring, backups and all the other shit you haven't been doing.

Because when you find out, I will laugh, it will be very very very funny to me.

taurath 5 hours ago|
Meanwhile a huge portion of management and leadership in software companies are encouraging everyone to de facto stop looking at code and let the LLM and a bunch of boundaries handle this for you.
rukuu001 5 hours ago|||
A couple high-profile crash & burns will get their attention.
jcgl 3 hours ago||
Just like well-publicized data breaches over the years got people’s attention? Color me skeptical.
protocolture 5 hours ago||||
Which is why you need someone who is responsible for IT security without also being responsible for shipping product. An asshole who can stop releases until security is properly in place.

My understanding is this bloke gets very quickly removed from Fortune 500 companies.

Which is why I am going to need a very large capacity popcorn bucket.

m_mueller 5 hours ago|||
“You are a CISO who needs to review and secure all our slop, and you never make mistakes or you get shut down immediately!”
LoganDark 4 hours ago||
"You are a Miso soup..."
acedTrex 6 hours ago||
Maybe all these vital infrastructure companies should not have spent the past decades in a race to the bottom of cybersecurity. There is going to be a reckoning.
dbdr 6 hours ago||
> Invest in formal verification, fuzzing and property testing, and memory-safe languages. LLMs are good at writing Lean and fuzz tests. I don't care whether you use Go or Rust but for the love of god please don't use C or C++ for new code.

How accepted is this thinking in your respective domains?

pjmlp 5 hours ago||
A lot, I am only writing C or C++ for new code when it is unavoidable, like existing code bases, bindings or tinkering with runtime implementations that aren't bootstraped.

Mobile platforms, distributed computing have long moved the spotligh away from C and C++, other than language runtimes or existing products from the 90's like SQL servers, and naturally UNIX like underlying OS, which most userspace developers aren't writing new code for.

Naturally there are domains like LLVM/GCC, console game dev, HPC/HFT where they are unavoidable for new code.

bsenftner 48 minutes ago||
The propaganda police are lying. There is nothing wrong with C/C++, you are just too lazy to handle your own memory, and you accepted that propaganda that "managing your own memory is hard" without even trying.

The idea that this terrible advice floats at all tell you how terrible educations are these days. The idea is ridiculous and yet nobody calls it what it is: it is stupid and those that follow that advice out of fear are dumber than rocks.

bamboozled 2 hours ago||
We had decades to avert the worst effects of climate change…batten down the hatches.
LoganDark 6 hours ago||
It's just the same advice as ever: be extremely, exceedingly careful in what you expose to any network. When I set up machines for production, they don't respond to pings and they don't even have an SSH port open without knocking. There are also ways to eschew the need for an SSH port entirely.

People who never took that seriously will never take this seriously either, and that's their loss. (And loss of the commons, unfortunately.)

There's just also new advice: you can't afford to expose an unsecured system to the internet even for a moment. Think of those IPv4 address space scanners, except this time any one of them could be capable of developing individualized attacks in mere minutes. They don't sleep, they don't take breaks.

Gigachad 5 hours ago||
That’s fine for your home server, but if you want an actual server that the general public can use, it has to be exposed to the internet.
hypfer 5 hours ago|||
Sure, but still, attack surface could and should be minimized by rethinking what exactly even needs to be on a server the general public can use.

There are a lot of security problems you can categorically rule out by simply not involving a cloud. Clouds have been involved in a lot of things, because everyone was doing it, and because that's how you can collect rent, but they aren't really necessary for most use-cases.

So we could definitely get the exposure down there. We'd just have to fundamentally shift the defaults of this industry.

jsiepkes 5 hours ago||||
But not everything needs to be directly exposed to the internet. Framework had their data leaked because their metabase instance was hacked with a zero-day. Why was it directly exposed to the Internet? Why not require the use of a VPN like a Wireguard based solution or Nebula for these "internal" kind of apps?
LoganDark 4 hours ago||
> Framework had their data leaked because their metabase instance was hacked with a zero-day.

No, Framework had their data leaked because they stored it in the cloud with Metabase the company, which got hacked. Not because of any vulnerability on-premises.

tgv 5 hours ago||||
Still, it doesn't have to ping back, and ssh can (should) be very restrictive.
Gigachad 4 hours ago||
Ping and ssh are pretty much never the things being hacked though. Turn password auth off and it’s very secure.

What gets hacked all the time is the actual web app itself. Which has to be exposed to be useful.

LoganDark 5 hours ago|||
I didn't say there are zero ports open, they're not my home server, I just said they're production servers. But exposing something like a properly configured nginx to the internet is way different from exposing application code directly. Most of my servers have used h2o (built from source because they don't cut releases anymore?) because I wanted HTTP2 and HTTP3 before anyone else would get their act together. These days I still use h2o because I like the config better than nginx, even though it's a pain to set up because nobody packages it (and they don't cut releases!)
darkwater 5 hours ago||
And then somebody driving an LLM will find your old and unsupported (how secure!) h2o server, find a 0day path traversal or RCE and own you.
LoganDark 5 hours ago||
h2o user doesn't have write access to anything on the system, not even its own config file. I don't think I disabled exec for it though. And I guess it could leak the HTTPS private key.

FWIW sufficiently secured software doesn't need to be updated. Doesn't matter if it's old and unsupported if there are no vulnerabilities in it.

That said, h2o is probably far from free of at least some vulnerabilities, not to mention all the layers below it. OpenSSL for example has had some vulnerabilities, and h2o depends on it.

I'm not saying I exactly practice what I preach. h2o's definitely a choice, but realistically I doubt anything's going to happen that I really care about.

darkwater 5 hours ago||
So how do you expose your legitimate service on the Internet?
LoganDark 5 hours ago||
By opening a port to a secure application. A secure application is usually one I wrote from scratch or one that's been battle-tested and hardened enough that even new vulnerabilities are not very useful.
jf 4 hours ago||
Another similar issue, with similar consequences and timeline, is Post Quantum Cryptography.
dikei 3 hours ago|
Not even close, Quantum Computer are still far from being able to do any cryptography cracking.
chris_wot 5 hours ago||
More tired “don’t use C or C++” advise.
mark_something 3 hours ago|
I wonder why C and C++ are usually regarded as equally insecure. In C you need to carefully check that you free allocated memory, and that you don't use it after you free it. In C++ this is automated by using classes like std::string and std::vector, once they go out of scope their memory is freed and you can't use it anymore. It is still possible, e.g. by using a for loop that iterates over a vector, and removing or adding stuff to that same vector in that loop. But my rough estimate is that such errors are at least ten times less likely in C++.

I develop in C++ for a job, and when I need to use a library written in C I always have a bad feeling about it.

keybored 3 hours ago|
Clanker fodder. Unless the We are heads of states/heads of spooks or the AI powers that be (praise be) that there is no power and will to do that in one year or even ten years.
More comments...