Morphit @ Morphit @feddit.uk

Posts

4

Comments

288

Joined

2 yr. ago

TL;DR: he wasn't banned, he quit:

https://www.instagram.com/p/C-A3yZiObH6/

On Saturday, I was perplexed by photos online of Trump boarding his plane en route to a bitcoin conference. There was no bandage on his right ear. I re-posted one of the photos on Twitter and wrote, “look closely at his ear that was ‘hit’ by a bullet from a AR-15 assault rifle.”⁣
⁣ “Fake news,” someone responded. “It’s the wrong ear,” said another, which of course was not true. “This is an old photo,” which I felt the need to reply to. I re-posted a screenshot of New York Times photographer Doug Mills’ Twitter post of the same situation of Trump boarding his plane, which included the date and time of his photo. Doug is one of Trump’s favorite photographers and Trump has publicly called him “my genius photographer.” So I thought the maga world would at least believe Doug Mills.⁣
⁣ They didn’t. The comments turned ugly. Mostly about me, but also some that disparaged Doug Mills. ⁣ ⁣ Since 2017, I’ve been accustomed to having vile and hateful comments thrown at me. But I had now exposed someone else, Doug Mills, to be the recipient of hateful messages on MY Twitter account. Not cool.⁣
⁣ On top of that, I’ve been at a cabin with no Internet and sporadic cell coverage for the past week, which made it difficult to post anything in the first place but also a challenge to push back against the hate.⁣
⁣ So I de-activated my Twitter account. It was a gut decision, made only by me. I am still not sure if this is a temporary or a permanent action.⁣
⁣ I was unaware that some on Twitter were a⁣ responding that Elon Musk had deleted my account. How would I know? I wasn’t able to access Twitter. I did receive a few DMs here on Instagram about this, but didn’t think much about it. ⁣ ⁣ Until…late last night, I received a text message from a New York Times reporter asking me to comment about my supposedly “being kicked off X for posting a photo of Trump’s ear.” And then this morning, I received a text message from a childhood friend who asked, in jest, “Is there a Free Pete Souza donation site?”⁣
⁣ It was time to respond. I have so much more I want to say about the state of social media, but for now I want to make it clear that I was not kicked off Twitter. I kicked myself off.⁣

I guess the funny thing is that each Git commit is internally just a file. Branches and tags are just links to specific commit files and of course commits link to their parents. If a branch gets deleted or jumped back to a previous commit, the orphaned commits are still left in the filesystem. Various Git actions can trigger a garbage collection, but unless you generate huge diffs, they usually stick around for a really long time. Determining if a commit is orphaned is work that Git usually doesn't bother doing. There's also a reflog that can let you recover lost commits if you make a mistake.

Except PGP is a substring of the 'technically correct' term. It's like someone saying you're playing on your Nintendo - "Um, actually it's a Nintendo 64."

I think Github keeps all the commits of forks in a single pool. So if someone commits a secret to one fork, that commit could be looked up in any of them, even if the one that was committed to was private/is deleted/no references exist to the commit.

The big issue is discovery. If no-one has pulled the leaky commit onto a fork, then the only way to access it is to guess the commit hash. Github makes this easier for you:

What’s more, Ayrey explained, you don’t even need the full identifying hash to access the commit. “If you know the first four characters of the identifier, GitHub will almost auto-complete the rest of the identifier for you,” he said, noting that with just sixty-five thousand possible combinations for those characters, that’s a small enough number to test all the possibilities.

I think all GitHub should do is prune orphaned commits from the auto-suggestion list. If someone grabbed the complete commit ID then they probably grabbed the content already anyway.

Ah - Actually reading the article reveals why this is actually an issue:

What's more, Ayrey explained, you don't even need the full identifying hash to access the commit. "If you know the first four characters of the identifier, GitHub will almost auto-complete the rest of the identifier for you," he said, noting that with just sixty-five thousand possible combinations for those characters, that's a small enough number to test all the possibilities.

So enumerating all the orphan commits wouldn't be that hard.

In any case if a secret has been publicly disclosed, you should always assume it's still out there. For sure, rotate your keys.

Well, sort of. GitHub certainly could refuse to render orphan commits. They pop up a banner saying so but I don't see why they should show the commit at all. They could still keep the data until it's garbage collected since a user might re-upload the commit in a new branch.

This seems like a non-issue though since someone who hasn't already seen the disclosed information would need to somehow determine the hash of the deleted commit.

I think they've changed the headline, but not the embedded video:

You fraud.

Yeah, they probably have it all figured out.

What do you mean? The shadow mask ensures the gun for each colour can only hit the phosphors of that colour. How would a lower resolution change that?

As far as we know, the input was a file filled with zeroes

CrowdStrike have said that was not the problem:

This is not related to null bytes contained within Channel File 291 or any other Channel File.

That said, their preliminary incident review doesn't give us much to go on as to what was wrong with the file.

You're speculating that it was something easy to test for by a third party. It certainly could have been but I would hope it's a more subtle bug which, as you say, can't be exhaustively tested for. Source code analysis definitely would have surfaced this bug so either they didn't bother looking or didn't bother fixing it.

How would you prove that no input exists that could crash a piece of code? The potential search space is enormous. Microsoft can't prevent drivers from accepting external input, so there's always a risk that something could trigger an undetected error in the code. Microsoft certainly ought to be fuzz testing drivers it certifies but that will only catch low hanging fruit. Unless they can see the source code, it's hard to determine for sure that there are no memory safety bugs.

The driver developers are the ones with the source code and should have been using analysis tools to find these kinds of memory safety errors. Or they could have written it in a memory safe language like Rust.

It's a proprietary config file. I think it's a list of rules to forbid certain behaviours on the system. Presumably it's downloaded by some userland service, but it has to be parsed by the kernel driver. I think the files get loaded ok but the driver crashes when iterating over an array of pointers. Possibly these are the rules and some have uninitialised pointers but this is speculation based on some kernel dumps on twitter. So the bug probably existed in the kernel driver for quite a while, but they pushed a (somehow) malformed config file that triggered the crash.

For this Channel File, yes. I don't know what the failure rate is - this article mentions 40-70%, but there could well be a lot of variance between different companies' machines.

The driver has presumably had this bug for some time, but they've never had a channel file trigger it before. I can't find any good information on how they deploy these channel files other than that they push several changes per day. One would hope these are always run by a diverse set of test machines to validate there's no impact to functionality but only they know the procedure there. It might vary based on how urgent a mitigation is or how invasive it'll be - though they could just be winging it. It'd be interesting to find out exactly how this all went down.

It should be relatively straightforward to script the recovery of cloud VM images (even without snapshots). Good luck getting the unwashed masses to follow a script to manually enter recovery mode and delete files in a critical area of the OS.

How does Falcon store these channel files on Linux? I don't know how an immutable distro would handle this given CrowdStrike push several of these updates per day and presumably use their own infrastructure to deploy them.

I guess if you pay them enough they could customize the deployment to work with whatever infrastructure you have but it's all proprietary so I have no idea if they're really doing that anywhere.

I'd have thought the cloud side would be pretty easy to script over. Presumably the images aren't encrypted from the host filesystem so just ensure each VM is off, mount its image, delete the offending files, unmount the image and start the VM back up. Check it works for a few test machines then let it rip on the whole fleet.

Same. I can see some of it in between popovers about my account being suspended, getting rate limited, or of course "something went wrong". I don't understand why there are people who still only post there.

It's a proprietary enterprise security product so I think it'll be difficult to get information until they give a proper post-mortem (if they do so). Here's hoping someone can put it all together though.

From what we have from CrowdStrike so far, the Channel File 291 update was to combat some use of Named Pipes in Windows malware.

This seems to have triggered a null pointer exception in the Falcon kernel driver as it loaded this Channel File. CrowdStrike say this is not related to the large null sections of one of the files but haven't really explained what did trigger it.

Regardless, the kernel driver ought to have been statically analysed to detect this kind of memory hazard, or written in a language that prevents this class of bugs altogether. This is a priority of the US government right now, but CrowdStrike doesn't seem to have got the memo.