UKC

Microsoft goes down - chaos ensues

New Topic
This topic has been archived, and won't accept reply postings.
 apache 19 Jul 2024

Microsoft has gone down. No 360. Total chaos in the USA and elsewhere. I've shut down the computer and gone running instead!

2
 Luke90 19 Jul 2024
In reply to apache:

To be fair to Microsoft, the issue seems to have been caused by Crowdstrike. Microsoft just seemed like the ones at fault initially because the computers Crowdstrike was running on were Windows ones.

 jonfun21 19 Jul 2024
In reply to apache:

Biggest global IT outage probably since WannaCry? Hopefully they can stop the update before it rolls out further across the world. 

Huge queues at a number of airports across the UK….or just another normal day if you are Birmingham Airport 

 will_mcmahon 19 Jul 2024
In reply to apache:

Luckily UKC hasn't gone down! That's the real crisis averted.

 nikoid 19 Jul 2024
In reply to apache:

I notice the statement from Crowdstrike didn't include an apology!

 Andy Johnson 19 Jul 2024
In reply to Luke90:

> To be fair to Microsoft, the issue seems to have been caused by Crowdstrike.

The Office 365 outage that @apache is referring to was caused by a problem on Microsoft's Azure cloud platform †. Nothing to do with the Cloudstrike global clusterf*k (which was itself nothing to do with Microsoft). Just a coincidence they happened on the same day.

https://www.bleepingcomputer.com/news/microsoft/major-microsoft-365-outage-...

Post edited at 14:52
1
In reply to apache:

A case study for the ages in the making. How on earth did this get through the various testing stages, and on Windows of all platforms not some esoteric random syatem, and only 8% hit on Crowdstrike shares at the time of writing.

Just bonkers

1
 Luke90 19 Jul 2024
In reply to Andy Johnson:

Yeah, you're right. It was pretty confusing this morning with the news reports struggling to differentiate between those two different issues. The Crowdstrike one does seem to have accounted for the majority of the disruption worldwide. As far as I can make out, the Azure issue largely happened in the night UK time and was resolved before many people here would have been working. Plus lots of services for UK folk wouldn't have been hosted on US servers anyway.

 wintertree 19 Jul 2024
In reply to Luke90:

> To be fair to Microsoft, the issue seems to have been caused by Crowdstrike. Microsoft just seemed like the ones at fault initially because the computers Crowdstrike was running on were Windows ones.

It is however Microsoft’s fault that a third party application is able to brick their operating system in a way that can’t be tribally recovered…

7
 Ciro 19 Jul 2024
In reply to wintertree:

> It is however Microsoft’s fault that a third party application is able to brick their operating system in a way that can’t be tribally recovered…

I'm not so sure. Third party security apps, by their nature, require privileged systems access. As such, if corporations aren't testing updates to those apps before allowing them into the production environment (as they would with a windows security patch) then they have to take a fair chunk of the blame.

 wintertree 19 Jul 2024
In reply to Ciro:

There’s privilege and there’s privilege.

No third party security has ring zero privilege, and you shouldn’t be able to BSOD from outside ring zero.

> then they have to take a fair chunk of the blame

I agree, but the idea Microsoft have no culpability doesn’t wash with me.  

4
 Luke90 19 Jul 2024
In reply to wintertree:

I don't know whether I'd hold them all that responsible, I'm dubious whether any normal operating system would be impervious to bricking by sufficiently broken software. And at least most devices still seemed to boot in safe mode for a fix.

 Baz P 19 Jul 2024
In reply to apache:

Whoever is to blame for this it should be a wake-up call. Just wait until the electricity goes off. 

 wintertree 19 Jul 2024
In reply to Luke90:

> I don't know whether I'd hold them all that responsible, I'm dubious whether any normal operating system would be impervious to bricking by sufficiently broken software

A key point of modern operating systems is to restrict the mischief one process can cause to others or to the kernel.   

Something in the privilege and security model is broken if this can happen.

Not exactly a revelation when it comes to Windows, so much as an illustration.

 CantClimbTom 19 Jul 2024
In reply to TheDrunkenBakers:

Yes/no

Mistakes happen, "it" happens. That's why in the old days patching was done midweek for Dev, the weekend for UAT, following weekend for Prod and then only after Prod was OK for a week or more would DR be patched (that way there was always a known-good DR to fail back to)

Why did everything get patched one Thursday evening, that's the far bigger concern

 CantClimbTom 19 Jul 2024
In reply to wintertree:

Nonsense man, look at bashdoor, XZ Utils and all the rest, no OS is invulnerable. It's not a Linux versus Windows versus whatever contest (as much as I enjoy kicking Windows)

Windows may not help , but idiocy combined with laziness is the underlying problem. People no longer care about getting the basics right. DevOps is brilliant but the ops part is increasingly getting neglected and this is the payback 

In reply to CantClimbTom:

> Yes/no

> Mistakes happen, "it" happens. That's why in the old days patching was done midweek for Dev, the weekend for UAT, following weekend for Prod and then only after Prod was OK for a week or more would DR be patched (that way there was always a known-good DR to fail back to)

> Why did everything get patched one Thursday evening, that's the far bigger concern

You're right, many questions need some quick answers.

I work in cybersecurity and also previously worked in automated SW testing.

I was also a previous investor in Crowdstrike and nearly ended up working for them too.

My employer has just emailed me saying we have issues too - we use Crowdstrike on our endpoints - but I've been thorning myself to buggery on an overgrown pyracantha today so won't know if my machine is affected until Monday morning. 

 CantClimbTom 19 Jul 2024
In reply to Luke90:

Bricking is by design, the software (Crowd strike Falcon Sensor) detects issues (a bit like intrusion detection, antivirus, etc) but goes a step further to "brick" well.. isolate.. the affected host if there's a serious problem it isolates it from your network although still allows communication between the host and Crowd strike cloud.

This means that an e.g. compromised/infected/vulnerable box can be taken off network. Necessarily it needs to be tightly integrated so that malware can't just disable the Falcon Sensor service. It's a huge advance in security... When it works that is.

But now you have a cloud service that can "brick" your servers (unless you restart in safe mode and fix that). You're trusting a someone else somewhere else not to brick your servers accidentally... Ooops!!!

 mondite 19 Jul 2024
In reply to wintertree:

> Not exactly a revelation when it comes to Windows, so much as an illustration.

There are reports of similar incidents impacting some Linux systems pretty recently.

Unless you go down the ultra locked down route, which has its own problems, if something has root access then it can cause mayhem.

1
 wintertree 19 Jul 2024
In reply to CantClimbTom:

> Nonsense man, look at bashdoor, XZ Utils and all the rest, no OS is invulnerable. 

I didn’t say any of the others were perfect.

> Windows may not help  

Indeed

> but idiocy combined with laziness is the underlying problem. People no longer care about getting the basics right. 

Agree. Far to much security and protection is bolted on afterthought, where as a project should start with the secure platform and then add features.

> DevOps is brilliant but the ops part is increasingly getting neglected and this is the payback 

… and yet there has never been a time when it’s been more important.

Post edited at 17:32
 Frank R. 19 Jul 2024
In reply to TheDrunkenBakers:

I still don't understand why ClownStrike didn't do at least a staged or a rolling update of their faulty definitions file, apart from some proper internal testing. Could have at least prevented some of the mess.

Oh well, they did in fact do a rolling update – it rolled all the way from Australia, Asia, Europe and USA by their respective time zones

Any climbers in IT having their weekend plans ruined by this Friday clusterf*ck, I'm sending you a virtual beer...

Post edited at 17:31
 Andy Johnson 19 Jul 2024
In reply to wintertree:

Crowdstrike installs a device driver because, as an endpoint security product, it needs to do "stuff" with kernel-level privileges. Nothing particularly unusual about that. But what seems to have happened is that (a) businesses deployed Cloudstrike extensively on business critical systems, (b) Cloudstrike updates automatically by downloading malware definitions over the net, (c) Crowdstrike updates every installation at the same time (bad, no staging), and last night they pushed-out a malware definition "channel file" that crashes the driver and takes down the os. Reboot and it crashes again. And again...

I'd argue that this is very little to do with Windows and a lot to do with end-user orgs exposing themselves to an uncontrolled risk (single vendor auto-updating software), and to Crowdstrike's shoddy testing and all-or-nothing update processes.

Linux isn't immune. Over on hackernews a guy is describing† how Crowdstrike took down their (presumably large) fleet of Debian-based servers recently. But because Crowdstrike  is not widely deployed on Linux, the effect wss contained. So this isn't a Windows problem per-se.

Anyway, they crashed the world. Quite a thing to do. Reminds me of SqlSlammer back in the day.

https://news.ycombinator.com/item?id=41005936

 wintertree 19 Jul 2024
In reply to Andy Johnson:

> Crowdstrike installs a device driver because, as an endpoint security product, it needs to do "stuff" with kernel-level privileges

Why does that need a device driver than appropriate ACLs to give the required privileges?  

> I'd argue that this is very little to do with Windows and a lot to do with 

I agree with all the other things you list, but...  A well designed OS wouldn’t require a device driver parsing content from the internet.  There would be a user process with appropriate access to disable network interface etc.  I don’t know if windows lacks that or if Crowdstrike are just not very capable.

> Linux isn’t immune

Didn’t say it was.

> So this isn't a Windows problem per-se.

I wrote a windows device driver once for a piece of hardware I made and sold. The Mac OS X (as it was then known) didn’t need a device driver because after setting the fine grained permissions I could access everything from userland. Forcing things in to device drivers due to poor ACLs and userland APIs opens the door to this stuff.  If I ever write another windows driver it’ll be too soon.

 wbo2 19 Jul 2024
In reply to wintertree:

Do you actually know how/what this defect did, or are you just basing this on conjecture/bias?  

 wintertree 19 Jul 2024
In reply to wbo2:

I’m basing my last reply to Andy Johnson based on what they said.

Otherwise I’m basing it on the idea that automatically updating third party stuff shouldn’t be able to BSOD.  The replies I’ve got amount to accepting this status quo because reasons.  I find that really odd.  

I do have a bias about windows, and both past security incidents and my experience of writing a device driver for it factor strongly. I’m not arguing other OSs are immune or perfect but that the response shouldn’t be just blame the provider but the OS for not being suitably robust.  

I think it’s quite reasonable to conjecture they too much code was privileged given what’s its done.

 Andy Johnson 19 Jul 2024
In reply to wintertree:

> Why does that need a device driver than appropriate ACLs to give the required privileges?  

Because the driver (presumably) need to do things with kernel-level privileges that arent possible in userland, and there arent ACLs for. Idk what but maybe packer filtering or process injection or the like. We're talking about an endpoint security product here, so...

Having written (only) one windows device driver myself, I find it hard to believe the Crowdstrike devs would choose to build one unless they needed to. They're a pain to debug.

>> Linux isnt immune

> Didn’t say it was.

Didnt say you did

> I wrote a windows device driver once for a piece of hardware I made and sold. The Mac OS X (as it was then known) didn’t need a device driver because after setting the fine grained permissions I could access everything from userland. Forcing things in to device drivers due to poor ACLs and userland APIs opens the door to this stuff.  If I ever write another windows driver it’ll be too soon.

(Something like FUSE? Ive done veey little development on Macs.)

I take your point. But that model gives the entire process  (albeit constrained by the ACLs) elevated privileges. At least the Linux/Windows approach partitions the privileged code in the driver.

 Andy Johnson 19 Jul 2024
In reply to wintertree:

(Just read this)

> Otherwise I’m basing it on the idea that automatically updating third party stuff shouldn’t be able to BSOD.  

Again I think you make good points. If this had been an accounting application downloading new tax rules then there wouldnt be a problem. But the combination of it being a security product requiring privileged access, and frequent updates due to emerging threats - together with poor data sanitation and parsing by Crowdstrike, is imo why we have this mess.

As a developer I'm extremely glad I'm sat under a tree in the garden with a beer right now, rather than having to help sort this out.

 wintertree 19 Jul 2024
In reply to Andy Johnson:

> Because the driver (presumably) need to do things with kernel-level privileges that arent possible in userland,

Exactly.

> and there arent ACLs for. 

Exactly.

> Idk what but maybe packer filtering

Quite possibly.  I have some stuff of my own doing packet filtering.  It runs in userland on OpenBSD where I have /dev/pf

This is part of my point, bare with me…

> or process injection or the like. We're talking about an endpoint security product here, so...

The possible horrors of driver code with access to do injection downloading content off the Internet would surely put any sane firm off…. Right…

> Having written (only) one windows device driver myself, I find it hard to believe the Crowdstrike devs would choose to build one unless they needed to.

Exactly… and if Windows doesn’t provide safe, segmented, ACLd access to things security plugins need, it’s forcing the situation where stuff like this happens.

> They're a pain to debug.

I absolutely hated doing it.  What I’d give to having modern static analysis tools.  Part of the problem was mistakes crashing the machine….  But many/most device drivers don’t need the kind of performance that requires an environment where that can crash the machine.  But that was the way it was.

> Something like FUSE? Ive done veey little development on Macs.

This was USB 2 endpoints for controlling an external device and receiving a lot of data from it.  The endpoints are available with a userland API on OS X vs requiring driver code in Windows 2k (no idea on current situation for windows).  FUSE is a similar approach I suppose as there’s a generic kernel driver that presents an API to userland, although the kernel part wasn’t robust enough to bad userland requests when last I used it.

>I take your point. But that model gives the entire process  (albeit constrained by the ACLs) elevated privileges. At least the Linux/Windows approach partitions the privileged code in the driver.

Problem is it forces a lot of unrelated code in to the driver as well.  If the code is trusted, being in the driver is surely worse than userland with adequate APIs and ACLed? 

The whole bloody field is terrifyingly complex and far too trust based and despite the critical importance of computers to so much stuff, far to much security is reactive.  This has been massive and it was an accident.  Some states are preparing for deliberate action and many doors are wide open.

Edit to reply to your second post:

> But the combination of it being a security product requiring privileged access, and frequent updates due to emerging threats - together with poor data sanitation and parsing by Crowdstrike, is imo why we have this mess.

Oh I’m clear they’ve effed up big time, but there’s 29 years of history going back to NT 3.51 as to how we got here, why such products are needed and what’s apparently forced them in to a catastrophically unreliable design.

> As a developer I'm extremely glad I'm sat under a tree in the garden with a beer right now, rather than having to help sort this out

I don’t get much time to write lower level code these days so it was quite fun to get in to /dev/pf recently for some operational stuff, but I’d agree I’m happy sat in my garden with a drink.

Post edited at 19:31
 wercat 19 Jul 2024
In reply to apache:

this is all rather mild compared to what would have happened if we hadn't worked so hard to pre-fix the Y2K bugs in advance.

Allegedly it was "all a fuss about nothing" according to some moronic lordly Brexiteer numbskulls!

It would have taken years to get everything working again with inability to process dates emebedded in millions of lines of legacy code, not all of it in high level languages (we had some low level routines called from PL/1 that couldn't do Y2K as it turned out.) Flights would have been grounded indefinitely from our "favourite airline".

Post edited at 20:10
1
 CantClimbTom 19 Jul 2024
In reply to wintertree:

You've still got the wrong end of the stick. This is software, agent or whatever you want to call it that is designed to be really nailed down so malicious stuff can't interfere with it.

It's nothing to do with NT3.51 heritage or ordinary user mode stuff or what you can do in /dev/pf. It's some horrible sh!!ty software that lurks deeply in crevices that are hard to get to.. by design, because of what it does. If it was "nice" and non privileged, malicious code could side step it or block it or hobble it somehow.

I'm not defending the code or the company or Windows (shudder...) but it's not written nicely how you might do it, by design because of what it does. If you think otherwise you're still missing the point

Post edited at 21:05
2
 wintertree 19 Jul 2024
In reply to CantClimbTom:

> You've still got the wrong end of the stick.

No, I haven’t.

It sounds an awful lot like code was running some of its tasks with a higher privilege than it needed to do them.

> It's nothing to do with NT3.51 heritage or ordinary user mode stuff or what you can do in /dev/of.

That’s the point.  The windows heritage doesn’t expose a load of stuff through /dev/xx (which isn’t a windows thing BTW).  That forces more stuff deeper into privilege than it should be.

> It's some horrible sh!!ty software that lurks deeply in crevices that are hard to get to.. by design,

Disagree.  With proper cryptographic verification of the payloads being downloaded, much of the code can live in less trusted layers with crypto validation but not processing of large datasets done in the kernel space.  You’re reaching for excuses when there are known ways of handling untrusted layers.

> because of what it does. If it was "nice" and non privileged, malicious code could side step it or block it or hobble it somehow.

Only because the OS has a flawed system that doesn’t do sufficient to protect processes from each other.  This product is trying to polish a turd, and when you do that you end up covered in shit.

You are conflating asking for protection with asking for privilege.  If as speculated by AJ and me the designers were forced in to that conflation, that tells you the problem right there.  Asking for privilege should be independent by design of being protected.  Bad designed forced by the history of Windows NT.

> I'm not defending the code or the company or Windows (shudder...) but it's not written nicely how you might do it, by design because of what it does. If you think otherwise you're still missing the point

No, I don’t think I am missing the point, at all.  A bad design forcing a conflation of protection and privilege.

“Just shove it all in the kernel, downloads and all” isn’t smart.  I’m surprised your taking such a defeatist view that it has to be this way, or that an OS should be so insecure people are willing to install third party divers to manage it.  We should have higher aspirations here.

Post edited at 21:22
1
 CantClimbTom 19 Jul 2024
In reply to wintertree:

I'm in part playing devil's advocate here and I'm not saying you're "wrong" per se, as much as I don't agree with your perspective. It just seems a bit glass half empty. I attribute most of the mess to widespread operational/management shortcuts as much as the underlying  design.

As you mention, there's the saying: "you can't polish a turd" but the retort is "but you can roll it in glitter". As an engineer I do find a lot of my time is spent glitter rolling people's stuff. Maybe I'm glass half full from too much glitter rolling

 wintertree 19 Jul 2024
In reply to CantClimbTom:

> It just seems a bit glass half empty.

I look at it that way because the level is dropping.   

> I attribute most of the mess to widespread operational/management shortcuts

For sure, it’s taken a lot of bad management decisions to get to the point a third party kernel driver downloading updates from the net is seen as a way to boost the security of its host OS.

> as much as the underlying design.

Plenty of blame to go around.  But my point that kicked this all off was that Microsoft have some of that share.  An OS so insecure it needs this kind of kernel driver?  An architecture that doesn’t orthogonalise protection and privilege?    The windows NT line has had 29 years of those management decisions you pin the blame on baked in to it now.  Mac Os is going the same way lately IMO.

The number of compromised open source libraries recently - and the OpenSSH vulnerability show it’s not great away from Microsoft either.

The recent ransomeware attack on the NHS was treated as almost inevitable.  I saw a US study in to how much mortality rates rise after such an attack.  It happens so often they can do statistics on the consequences.

I’m agog at how normalised this has become and how low people’s expectations are for OS security. It’s not healthy.

 mondite 19 Jul 2024
In reply to wintertree:

> Plenty of blame to go around.  But my point that kicked this all off was that Microsoft have some of that share. 

Not really. Or are you blaming Linux and Apple as well? Both of which Crowdstrike provide software for? Oddly enough in the tech forums been several comments about how similar things have happened to Linux in the past its just its hit one or two particular distro versions vs across the board.

The problem is a properly secure OS is also one which is a complete arse to use day to day.  You could go for sandboxing every app but then that would have a few awkward repercussions.

> I’m agog at how normalised this has become and how low people’s expectations are for OS security. It’s not healthy.

MS have done a reasonable job in regaining ground. Its why standard AV and firewall companies are struggling now with Defender doing the job. However enterprise in particular tend to want bells and whistles.

1
 wintertree 19 Jul 2024
In reply to mondite:

> Not really. Or are you blaming Linux and Apple as well?

Not for the crash of windows computers, no.  That would seem pretty dumb, would it not?

> Both of which Crowdstrike provide software for? Oddly enough in the tech forums been several comments about how similar things have happened to Linux in the past

It’s hard to blame “Linux” given there isn’t a single clear entity behind its many forms, but I also haven’t once held Linux up as a positive counter example…

> The problem is a properly secure OS is also one which is a complete arse to use day to day.  You could go for sandboxing every app but then that would have a few awkward repercussions.

The gulf between where we are with Windows, macOS and Linux and a properly security hardened OS is almost immeasurable,  there’s a big juicy middle ground where security is baked in from the start, not bolted on in a half arsed way with third part programs and now kernels drivers/kexts.  

> MS have done a reasonable job in regaining ground. Its why standard AV and firewall companies are struggling now with Defender doing the job.

Microsoft are doing a reasonable job at beating AV and firewall companies at fixing the mess Microsoft enabled.

If MS were doing a reasonable job all round on the security of their OS, they would be no mess to fix.

> However enterprise in particular tend to want bells and whistles.

To be fair, any enterprise that settles on a kernel driver that auto updates as part of its “solution” is as much to blame…

It’s 2024 and a whole lot of kernel code is still written in a pair of languages that don’t bounds check anything.  I just can’t comprehend why so many people’s expectations are so low. 

Post edited at 23:21
4
 abcdefg 19 Jul 2024
In reply to Luke90:

> To be fair to Microsoft, the issue seems to have been caused by Crowdstrike. Microsoft just seemed like the ones at fault initially because the computers Crowdstrike was running on were Windows ones.

Where can I find a detailed description of what exactly Crowdstrike's 'Falcon' product does? I'm a time-served Unix sysadmin, but I haven't yet got any handle on what's going on.

Post edited at 23:38
 abcdefg 20 Jul 2024
In reply to wintertree:

> No third party security has ring zero privilege ...

If it's a kernel module, it will have.

 wintertree 20 Jul 2024
In reply to abcdefg:

> If it's a kernel module, it will have.

Yes. See the later posts between myself and Andy Johnson.  I was previously wrongly assuming nobody would be insane enough to make a kernel module that downloaded and parses lists from the Internet or auto updates itself….  Because that would be really dumb…

Post edited at 00:23
2
 Lankyman 20 Jul 2024
In reply to apache:

Glad I've got some cash under the bed

 sandrow 20 Jul 2024
In reply to Andy Johnson:

Weird that you should get a downvote for this!

1st thing yesterday morning Azure service health page was reporting that a network device misconfiguration in US Central (aka DNS change) had "spread" to other regions in the US and was taking Azure hosts offline, impacting M365 and other services. MS managed to stop the spread so UK hosted services weren't affected. As a lot of multinationals use US hosting by default - some UK and worldwide users were impacted.

Not sure what the status of this incident is.

Just signed in again and there is no mention of the Azure outage - all it mentions is the Crowdstrike Falcon fiasco - no mention in history of the US Central outage.

The US is more affected than anywhere else - how much of this is down to the Azure outage and how much due to Crowdstrike?

 BusyLizzie 20 Jul 2024
In reply to apache:

This is very surreal. I'm on Lundy, with limited Internet and very little sense that there is a real world across the water.

 Ramblin dave 20 Jul 2024
In reply to Andy Johnson:

> Crowdstrike installs a device driver because, as an endpoint security product, it needs to do "stuff" with kernel-level privileges. Nothing particularly unusual about that. But what seems to have happened is that (a) businesses deployed Cloudstrike extensively on business critical systems, (b) Cloudstrike updates automatically by downloading malware definitions over the net, (c) Crowdstrike updates every installation at the same time (bad, no staging), and last night they pushed-out a malware definition "channel file" that crashes the driver and takes down the os. Reboot and it crashes again. And again...

Yeah, agree, this is what seems really problematic. Critical systems exist and get updated, updates sometimes fritz servers, you mitigate against this by having redundancy and staged updates. You don't put yourself in a position where a risky update - which is to say any update, really - gets applied to more than one node until you've verified that it works on the first one. I don't see why AV should be different in this respect.

To BSOD one server might be considered misfortune, to BSOD all of them is definitely carelessness. 

Post edited at 10:15
1
 Offwidth 23 Jul 2024
In reply to Ramblin dave:

Microsoft blame the EU competition policy for the outage !!??

https://www.euronews.com/next/2024/07/22/microsoft-says-eu-to-blame-for-the...

 Alkis 23 Jul 2024
In reply to Offwidth:

Yes. They were legislatively forced to allow ring-0 access to AV makers.

Edit: There is an interesting chicken and egg situation here. The AV makers want access so that they can provide a solution that operates at a low enough level to detect rootkits etc. Allowing access makes it easier for root kits to even exist.

Post edited at 13:23
 Offwidth 23 Jul 2024
In reply to Alkis:

Well if we want fair markets the likes of Microsoft should be able to cope. It's hardly like they could be trusted to never release partially operating software that was easy to hack 

4
 Alkis 23 Jul 2024
In reply to Offwidth:

If MS, or any OS maker for that matter, were to release a fully secure OS, nothing but boot drivers would run in kernel mode. 

Crowdstrike managed to brick some Linux servers a few months ago with a similar mishap.

Edit: IMO, that should teach companies how good an idea it is to trust ex-McAffee people… 😉

Post edited at 13:26
 Tricky Dicky 24 Jul 2024
In reply to apache:

Personally I think that my first few days working at Crowdstrike didn't go too badly, after all, everyone makes a few mistakes.....................

 wercat 24 Jul 2024
In reply to Offwidth:

Vulnerability is what Microsoft made its name with.  Boot secta infectas were possible by Microsoft design from the very beginning.  No reason why the tradition shouldn't continue.

1
 wercat 24 Jul 2024
In reply to Alkis:

I've always liked the idea of an encrypted CPU instruction set with a unique key for every CPU

A bit like no 2 brains being wired the same way

 mondite 24 Jul 2024
In reply to Tricky Dicky:

> Personally I think that my first few days working at Crowdstrike didn't go too badly, after all, everyone makes a few mistakes.....................

Were you also in charge of the $10 ubereats giftcard for their partners who have been mildly inconvienced?

https://techcrunch.com/2024/07/24/crowdstrike-offers-a-10-apology-gift-card...

Got to wonder who thought that was a good idea. 


New Topic
This topic has been archived, and won't accept reply postings.
Loading Notifications...