Random Thoughts.....What Are You Thinking?

Some engineer at CrowdStrike wanted to buy extra stock and pushed this shitty patch to cause the price to dip.

Atleast thats my theory.

I highly doubt that's the case.

It's unlikely one engineer is able to commit a patch to a kernel driver that gets deployed into an update with no review or testing. More than likely the issue is either related to release management and/or testing not being performed properly combined with a bad commit. It'd be a massive failure if one employee could pull this off to manipulate stock prices, it'd also be extremely obvious.

And yet all those eyes pushed through system crashing bug that crippled millions of systems overnight.

Its not like this bug affected a handful of systems under niche conditions. This isnt "we broke the cure forumula and now undead are getting OHKO from cure 1", literally every system running windows (and CrowdStrike obviously) was affected, this bug should have been noticed immediately.


Although, this is not as bad as the old windows 10 bug that affected certain Intel systems and deleted files on their own.

related:
https://x.com/vinceflibustier/status/1814233715641389456

I know its fake, but still funny, and the replies.

Yea, agreed. It's not clear how it happened, but again I doubt it's malicious or intentional. There are a number of ways even the most obvious of bugs could get deployed, but without knowing the details of the bug, their release process, or their testing process, it's hard to know for sure how. If their processes are so shitty that they don't find something like this in early deployment at the latest then it was inevitable, but how something this obvious ended up out there is hard to know without more information. I've seen really similar scenarios almost play out on a smaller scale with kernel modules and only get found early in the release process, all for varying reasons, none intentional or malicious. Many test environments also don't fully reflect what a production system is doing, which can be a huge issue as well for certain bug types.

The only reason it impacted millions of devices is due to CrowdStrike's reach combined with how nonchalant people are about installing kernel drivers. They assume the people who wrote them know what they are doing. Critical infrastructure, embedded devices, etc need to be more selective, but that's a battle I've fought and repeatedly lost because people just assume folks writing kernel code know what they are doing and take it seriously (spoiler: they often don't), if they even know what it means to begin with (see above).

Like I said:
I didnt really have a choice

That wasn't aimed at you, rather the people who did the forcing without regard for what it meant, same applies for orgs who mandate it goes on all of their devices without caveat or exception.

IMO it's also a little different for workstations than it is things like backend servers, databases, etc.

looks really good i added on my wish list think im gona get after king arthur knight tale

More 2 hours into FF13 and Im starting to see some structure. Ch1 is the introduction, ch2 is the context, by starting to explain the worlds rules, ch3 is basically a battle, mechanics and enhancement tutorial.

I also spent some time reading the short summaries in Catalog, and got a gist of it. The many weird and non intuitive names makes things more obscure than what they should, but so far, it seems a retelling of idk genos conflicts like we always hae in the world? With some neo stuffs ingrained on it to make it more diguised and more dramatic.

I tried replaying on my steam deck and I got bored, I have never finished it. I like a lot of things about it except actually playing it

I dont know enough about coding to verify any of this, but it sounds like its a bug that is so easy to avoid it should never have manifested?

https://x.com/Perpetualmaniac/status/1814376668095754753

saying this problem is the programmers fault is like saying that an airplane crashing is pilots fault

It literally is the programmers fault though lol

The programmer doesn't have a say in the change control process- a process which in place because programmers *** up is just a fact of doing business. If the programmer royally *** up, it's someone else's whole job description to identify that and make sure the world is insulated from that, and THAT person (or department) is who CANNOT *** up.

We don't know if the process was lacking to begin with, or it was good but not followed due to human error or whatever reason.

Good morning you who are a programmer that screwed up in your patch.

Dont worry, its always the fault of the infrastructure team. Dont let them say the opposite.

Human errors arent a possibility. They are a certainly.

But protection and mitigation systems should be garanteed. And not a possibility.

If there is only one culprit, there is only one possibility...

I kinda saw it coming when you said it is a job from "private insurance firm"....

Yay, finally got my fair win again Titan AI in AoM.

Take that your frigging algorithm

The existing driver should have null checked anything it was pulling in from the definitions file. This has probably been in place for years, so dozens if not hundreds of people didn't bother adding a safety check they should have. This is an easy check that anyone who has ever written C++ is capable of adding.

The definitions file handing in nulls should have been through review prior to hitting production. This is obviously a tooling or process error, but it's something that anyone who knows the definition file structure would immediately recognize if they so much as looked at it. The person who put in the bad file holds some responsibility for the overall event, but one person should not be able to push anything relating to kernel level code to tens of millions of computers.

Even if you want to blame the person who pushed the bad file for all of this, there is a bigger issue at play here. If one person can push updates at this scale without review, imagine if a bad actor was in that job. Instead of having to do a mildly inconvenient repair step, they could have used this to do intentional damage of a comparable scale. It reflects extremely poorly on a security software[though my impression is that it's less about security and more about spying on employees].

Windows 11 is trash.

I keep a little dirt under my pillow for The Dirt Man~
In case he comes to town~
I keep a little dirt under my pillow for The Dirt Man~
So he won't take me down~
To his lair~
Deep under the mountain~
Underground~
That's where he keeps his dirt!

It really isn't. I mean a small part of the blame, sure, but testing and release processes should've stopped this long before it was pushed on a global scale. If one developer making a mistake can bring down half the global infrastructure then that is the real problem, intentional or not. You need to assume someone is going to make a mistake.

I've worked with similar situations before. I helped manage some kernel modules that were deployed on a wide scale. The test process was as thorough as possible (it's not trivial ensuring full code coverage) and release process ran from starting with a handful of instances for several days to deploying across the entire range in phases across a period of weeks. There was more that one instance where issues weren't identified until they started rolling out to actual instances, because simulating actual usage is very difficult, and we realized there was a problem once it started going onto real instances. In this case they should've deployed to a smaller scale, let it sit for a while, then roll out gradually instead of just hit go. It's also possible that it was identified as an issue but the release went on anyway due to a communication problem or other issue. You need safeguards in check to sign off on releases to prevent this sort of thing. There are multiple points of failure here, but the dev is the least significant IMO.

It's also my understanding CrowdStrike doesn't provide an interface or ability for updates to be deferred or staged for testing, which is something most large orgs do with updates to prevent this exact scenario. Not being able to do this with an update to a kernel driver is terrifying.

So yea the dev made a mistake, but the real problem here is you have software that can't be staged or tested by customers in a staging environment that is deployed with some massively insufficient or flawed test/release process. There should have been multiple checks in place between the dev making the commit and it ending up on this many devices.


The dirty not-so-secret of the security industry is that the vast majority of security software is very poorly written, this has been discussed at length for years. With your RE experience, you could pretty readily load an AV driver into IDA and you'd be shocked at how horrid most of them are and how they do a lot of things in the kernel that should be done in userspace, if they should be done at all. I admittedly haven't looked at any myself in 5+ years but I'd be surprised if that has changed at all given the decade+ this was the case in the past. They rarely take their own advice or follow best practices, then depend on their internal teams to test/evaluate their software, most of which don't know much about evaluating native code applications much less kernel drivers, so they end up with a lot of issues, some of which fall into the top 5 dumbest things I've ever seen.

This is less of an issue for most end users on workstations, but in high security environments where you are a risk of being targeted by nation states, they pose more risk than they mitigate by a long shot (they are also absurdly easy to bypass in many cases with simple obfuscation).

I see a bunch of replies saying "well its not the dev's fault, I mean it is, but its a bigger problem that the glaring obvious bug actually made it through to production onto master and pushed to the world".

The problem started with the dev who input that piece of code. Yes, there were multiple problems along the way after that which caused a nearly 75 billion dollar company to shut down millions of essential services around the world with a catastrophic bug that should have never made it out to the world, but it still started with one programmer inputting a piece of code that, from what I read in that thread, should never have manifested to begin with.

we should not let Pantafrando post in ffxiah until he Re subscribes to the game

Pantafrando is an ***.

Dont trust him

Coding error isnt a possibility. Its a certainty. Humans make mistake, and thats something 10 out 10 persons will agree with it.

Thats why there are so many techniques, strategies, controls to mitigate this. So, the big surprise here is how all those defense layers failed at same time.

But if you still want to blame the human being, I would blame more the manager or the person who hired the dev. Surely you could employ better interview techniques or train better teams or add pairs to better code instead of leaving low quality devs with the main product of the company.

https://www.crowdstrike.com/careers/diversity-equity-and-inclusion/

Gundam Breaker 4 open network test is on today.
Gameplay feels pretty good; close enough to GB1/2/3, but with some new twists with the new dual wield combos stuff. I've stuck mostly to dual sabers, but saber/axe is interesting too. Wish they'd included whips in the test too because they looked nuts, but I'll have to wait for full release to test those.

Most of my time has been spent *** around in the builder (as tends to be the case with these games), because it's great. Left and right arms being seperate is a nice change, though I still tend to find myself matching them anyway just for aesthetics lol. Speaking of aesthetics; having paint presets based on the kits you've acquired is great too. Easy to slap something on if you're not in the mood to fiddle with paintjobs.

But the parts scaling is probably the biggest thing for me; it opens up so many more options now that you don't have to worry as much about the size difference between mobile suits.
Also, the scaling on builders parts is crazy. They scale along with the part they're attached to, but also have their own scaling option. So you can make them hilariously over/undersized by utilizing both sliders.So yeah, ***'s fun. Nice comeback after the insult that was New Gundam Breaker. If only SE could pull something similar with Dissidia.
Only one more month to wait. Q('w'Q)

I will demote you from Nynja to Genyn