Also the APT and RPM world lets packages sit for a long time - those are called "testing" and "unstable" in the Debian world. It's slow, but it seems hard to move intentional exploits with short-term payoffs through as far as we can see.
That's also why I am actively moving a fundamental and important internal service we have to just use python dependencies packaged in Debian stable packages. Sure, it may be a year or two behind in features, I may loose a nice debugging tool or two, but it is a very stable footprint, has security updates, breaks rarely. For ops-internal scripting and tooling, it's good.
Also, from the customer side, people ask at the higher end, don't they? Beyond a certain level, it's more of a search and a quest than just browsing. So you mainly have to show that you have connections for certain things. Why does this sound like drugs now?
I know this from a few friends who are deep into tabletop and boardgames, and they would regularly work with the one or two small stores around to get some special, expensive item (to help keep the shop afloat).
Yeah, in my experience the people who want niche stuff are willing to work with you and have a "high touch" experience. Where the people who want entry-level stuff want turn-key, sane defaults.
The annoying thing is people with lots of money and no experience who want the special expensive thing but they want it now and they don't know what options they want. I'm sure other fields are good at separating fools and their money but niche hobby retail isn't the Audi dealership, we're not just trying to upsell you for fun.
Women in a committed relationship can enter a medical situation that renders then unable to work for 6-9 months, + 2 - 3 years of leave afterwards. Men don't, that's just a month or two twice.
It is illegal, and in my book also immoral to deny such a candidate, but the other side of the coin is there.
A friend of mine had an interesting point there. It was more on a personal note that either of us had a hard time spending money on nice things for ourselves. Like, do you need better headphones, do you need this, do you really need that? Better not buy anything nice or fun.
A fairly unintuitive resolution to this is to setup a "fun and nonsense" budget and force yourself to spend it every half year, or to make a conscious plan on how to spend it over the year. If you plan the budget right, it won't hurt you, but it will force you to make your life better.
Maintenance, especially of owned property, seems similar to me. You should be saving up for the real "oh shit" situations, and you should accumulate a budget to just do things continuously. 6 months of routine maintenance budget saved up, what do we spend it on actively, before it becomes a mess?
Three deterministic Linux LPEs in a week, an LPE in BSD in execve (of all things...), nginx vulnerabilities, one or two new gnarly supply chain attacks. Linus noting that the linux-security mailing list is getting flooded with duplicated, AI-driven reports of varying quality. There are pretty crazy keycloak vulnerabilities getting discovered.
We're most likely entering a year or two or rapid vulnerability discovery, patching, as well as reducing and minimalizing system footprints just to survive the onslaught of strange vulnerabilities from e.g. ancient and widely unused kernel modules.
"Molten" to me implies it is still liquid. Molten salt reactors, molten magma from a volcano, molten sand, molten steel, dipping something into molten cheese. All fluid.
If I was to nitpick, "melted" is kind of inaccurate and not entirely natural in this context. Technically, molten sand is also melted sand, because that's how you get it to that state? Usually, you'd hear about solidified magma, crystalized sand, cast iron, air-cast steel, unevenly settled corium... to make a better point on how it turned back into a solid and what to expect from it - something like "The molten sand crystalized into an unusual structure" would be clearer.
I'd usually rather hear "melted" if it is important to note that this had a phase change and back. Plastic on an electrical device may look melted, indicating heat. A hardened steel part may look melted, which may damage the hardening. Rubber on a hydraulic line may look melted, also indicating heat. A plastic container looking melted in the context of chemicals may indicate some compromise.
And I do think that security research should have some regulation about it, but it should be more about responsible handling of the privileged access you gained, or a responsibility to disclose found vulnerabilities in private and/or to a government entity. You know, "If you have gained access to a system, and you saw a button <Turn off cooling pump 2> and you pressed it, you are on the hook for the damages". That is common practice with paid pentesters already.
But we're at a point where a court had do decide if discovering an endpoint on an API without authorization is a "circumvention of a security boundary" or not. Luckily, we now have a ruling that accessing API endpoints without authorization logic is no circumvention of a security boundary, due to a lack of a security boundary like authorization.
That's the level we are at. I don't want to know what happens if foreign nation state actors start acting on this seriously.
The mere act of scanning for vulnerability often causes outages.
I once ran a vulnerability scan at an industrial company that completely disabled their employees ability to clock in and out. I didnt believe it had anything to do with my scanner at first, but it ran on a schedule and the scanners schedule matched their outages eaxctly.
Eventually it turned out the timecard system had these IOT badge readers with a poorly written tcp stack. It would ACK every SYN, and worse the half open connections never closed, so during a port scan every port was left open until it exhausted the memory on the little buggers.
My point is... you cant know in advance what damage you'll do with this sort of testing. That's kind of the entire reason we have to actually perform the real world tests instead of assuming or emulating them.
It's also the reason that real world scanning without authorization is probably already a crime in most jurisdictions, whether it's enforced or not.
But in a perfect world, the question would be: Is it reasonable to expect an outage by sending a few single TCP packet to a system? Or, were you flooding the system unreasonably?
It is a huge security risk to treat systems as ancient eggshells you must not touch ever. A certain amount of touching has to be reasonable, because that is what foreign actors will do if they need to cause trouble. Apparently you could cause this company major operational harm with a pi zero. Why is that protected by professional ruin and jail time?
> Is it reasonable to expect an outage by sending a few single TCP packet to a system?
Thats kind of the rub isn't it? If I'm authorized to do the scan its reasonable. If I'm unauthorized nothing I do is reasonable.
It' similar to drivers licenses. If you get in an accident that wasn't your fault, but your license was invalid, its still your fault legally because you weren't meant to be on the road at all.
> There are times when this is good, there are times when actively trying introduce an improvement is the best way forward. A good senior is able to recognise when those times are.
This is what I was thinking - I'd say the biggest step up a developer can make is to recognize that sometimes you need a bit of one approach, sometimes a bit of another one.
Sometimes minimalism is the way, and you need to wonder if the pain, workload or lacking capabilities and features are problematic. Or, sometimes adding the smallest possible thing is a good way, as long as we don't paint ourself into a corner and enable learning and accumulating information of what we actually need.
Sometimes buying a thing is a good way, if you can find a good vendor and a tool fitting your use case and especially if the effort of doing it on your own is high. This commonly occurs in security, because keeping up to date with the ongoing vulnerability and threat landscape can be a full job on its own.
And sometimes adding something bigger is the way, if the effort of maintaining it are less than the effort and pain incurred by not having it. Or if we can ramp up the effort of the thing incrementally, while reaping benefits along the way. This can be validated often by doing a small thing.
What the AI will do in my opinion is to push the bar more in this direction. Cozily hacking CRUD-Code in a web server together most likely won't be enough in a year or two for the average development job.
The CVEs here have their fair share of silly C problems, but also more rigid input validation and handling. These more rigid validations exclude stuff which may even be valid by the spec, but entirely problematic in practice.
As examples, take a look how many valid XML documents are practically considered unsafe and not parsed, for example due to recursive entity expansion. This renders the parsers not flawless and in fact not in spec.
Or, my favorite bait - there should be a maximum length limit on passwords. Why would you ever need a kilobyte sized password?
That's also why I am actively moving a fundamental and important internal service we have to just use python dependencies packaged in Debian stable packages. Sure, it may be a year or two behind in features, I may loose a nice debugging tool or two, but it is a very stable footprint, has security updates, breaks rarely. For ops-internal scripting and tooling, it's good.
reply