They are/were scanning random public projects and creating unsolicited bugs in those projects to chide them about profanity in their source code. The linked thread is just a bunch of the victims of that spam having some fun with the format.
In the case of this attack, somewhere between 40s and 30min of physical access, depending on how the card was set up. In the case of a hotel, the spicy card to clone would be the cleaning staff's, which conveniently also admits a reasonable explanation for the card going temporarily missing (e.g. abandon it one corridor over, oops must have dropped it while doing the rounds).
Depending on the specifics of a deployment, I'm guessing you could also use the card secrets to mint new cards that authenticate correctly to facility readers, but contain different information? But I don't know nearly enough about how these cards get used to know how much flexibility you get there.
> But I don't know nearly enough about how these cards get used to know how much flexibility you get there.
A lot of systems still just use the UID.
Physical security/door access control is still completely disconnected from IT security, despite these systems relying on software for the last 20 years. As such, there is generally no knowledge in the buyers of such systems as to the risks and how to test for any vulnerabilities.
I bet systems which rely on the UID only (something even the card manufacturer specifically warns against in their datasheet) are still being sold, and lots are definitely still out there. This is trivial to clone and requires only a single read of the card, no cracking needed because the UID isn’t designed to be private to begin with.
I know only one access system that is built on Mifare and does not use UID, and that thing uses a file on the card as a bitfield of what doors it can open.
Possibly so. It just means that based on the report's findings, even if you'd decided to play it safe and buy exclusively from NXP directly (the creators of this ecosystem and owners of the MIFARE trademark), it looks like you could still end up with backdoored hardware.
Sorry if I was being unclear with my compound snark, but using a MIFARE Classic of any provenance would be a firing offense for the CISO of my daydream company.
Indeed. Alas (or fortunately depending which colour team you work on), fully broken Mifare Classic is still all over the place, and likewise the "hardened" variant broken in this paper :(
MIFARE DESFire is an option. In a genral public reseller, I found 100 DESFire cards sold for 146€ (tax excluded), while 100 of the equivalent versions as MIFARE Classic are sold for 109€ (tax excluded). This is a differnce of 37 cents by card, MIFARE Classic are about 25% less expensive than MIFARE DESFire. I guess the difference increase with the quantity you buy at once.
Maybe for greenfield deployment… but there’s all the existing infrastructure to support.
I still see classic being installed for door/gate systems in American apartments that are under active construction in 2024. Presumably that’s because resellers either don’t know better or they just have a massive inventory.
I still see new apartment buildings with Sentex or Linear call boxes with the factory master passwords. I don't think these guys are crack security experts.
They found the exact same backdoor key present on old NXP and Infineon cards produced as early as 1996. See p.11:
> But, quite surprisingly, some other cards, aside from the Fudan ones, accept the same backdoor authentication commands using the same key as for the FM11RF08!
> ...
> - Infineon SLE66R35 possibly produced at least during a period 1996-20136 ;
> - NXP MF1ICS5003 produced at least between 1998 and 2000 ;
> - NXP MF1ICS5004 produced at least in 2001.
> ...
> Additionally, what are we to make of the fact that old NXP and Infineon cards share the very same backdoor key?
I think it's more likely those NXP/Infineon parts are counterfeits. Look at A.12, there are early cards that don't NACK $F000 but claim to be NXP or Infineon, behavior counter to legit parts. It looks like the Chinese copies started to chameleon that behavior later as well.
Please, name these academic Unixes! I would love to go see what they do. Down-thread there's a mention of minix, which does the normal thing: demand paging, context switches only the page table directory pointer, and process memory images are moved around the storage hierarchy indirectly, through page faults. Which other academic Unix or Unix-like did you have in mind?
Linux is indeed not the owner of the concept of PID 0. It's fortunate that I didn't say that! It is, however, not frequently involved with paging in and out memory.
xv6 and its many forks are what I'm thinking about
You address this somewhat in the post:
> Going back to the Wikipedia article, it seems the author of that edit wanted to write “swapping”, in the classic Unix V5 sense of swapping out whole processes as a consequence of scheduling. But the edit didn’t clarify that “swapping” was being used in an archaic sense that was likely to confuse the modern reader.
> context switches only the page table directory pointer
Swapping out the the PTD pointer is exactly what I'm thinking of. I'm wrong, because I didn't have the common colloquial meaning of "swapping" (paging out memory to disk) in my mind
I think it's a little strange such a meaning has come to dominate, at least in a classroom setting it is still fairly common to discuss the operation of the scheduler as "swapping pages".
Yeah, admittedly it's confusing terminology generally, because it's still natural to say you're swapping the page tables out when you do a context switch on current systems. I probably do at some point in the post!
The distinction I was trying to get at was that, in early Unix, all process bytes were being actively streamed to and from disk as part of scheduling because the hardware didn't yet have a concept of virtual memory. So, if you wanted to make a program ready to run, you had to fully load it into memory, and shove anything else out of the way right then and there. That makes the scheduling function 5% deciding what should run, and 95% playing memory sokoban to make that happen.
OTOH, on systems with paged virtual memory, the scheduler is almost entirely "what's a good thing to run?", and implementing that decision is updating a couple of pointers. The only place the memory hierarchy creeps in, is if the scheduling algorithm wants to be fancy and account for things like NUMA nodes in its ranking of tasks.
I think it's reasonable, looking at it in isolation, to describe this part of the kernel as a "swapper", or the operation as "swapping". I think where it turns into a bear trap is when presenting these concepts to folks less familiar with kernel internals, where words like "swap" and "pages" are firmly the domain of the memory subsystem. And so, if I hand them a task and say "this is the swapper", IMO the majority will interpret that as being a component of virtual memory management, and they wouldn't be at fault for thinking that.
Empirically this happened in the 2008 wikipedia edit: "swapping" mutated to "paging" because in modern vmm-land that's a valid synonym, and that in turn became "this task is sometimes called 'sched' for historical reasons, and it handles paging" on the web. And cue a decade of confused students and stackoverflow users asking followups like "but if this task does paging, why does linux have all these kswapd threads?" That to me suggests that, for better or worse, the memory subsystem owns those words now, and the rest of the kernel has to be very careful if it uses them to mean something else, if it wants to avoid casual onlookers creating false associations. Something something naming things is still the hardest thing in computer science :)
It's not a problem, never has been. Nix mirrors all source bundles it pulls from third parties and caches them. cache.nixos.org has a copy of all the sources needed to build not just current HEAD, but also past commits (although deep history might start getting pruned for cost control soon, iiuc).
Are they storing source archives for each version? I'd think mirroring the actual repo might take less space than a bunch of copies of source archives.
Though it looks like git only uses deflate on pack files. Someone should write a patch to add lzma support. :-)
In this instance then, it sounds like it has cached the source with a backdoor in it, and anyone using it is potentially exposing themselves to a very public problem right now.
Also no. It was rolled back hours ago, and cache.nixos.org keeps all past builds so it didn't even need rebuilding.
Orthogonal to that, the backdoor was irrelevant to nix in at least three different ways: the malicious build logic targeted rpm/deb build environments and so didn't trigger in nix's build sandbox, the backdoor code makes assumptions about filesystem layout that are invalid on nixos and so wouldn't have activated anyway, and nix doesn't include the downstream patch that results in the backdoor even getting into sshd's address space. Still got rolled back out of an abundance of caution, but nix got lucky that the attacker didn't bother targeting it the way they did debian and rpm-based distros.
Worth noting that, like many immediate mode UIs, it seems to not integrate with OS accessibility infrastructure at all. That means any UI built with it will be a black box to anyone who needs accessibility tools like VoiceOver, text magnification, or semantic navigation.
It should be. There's AccessKit integration in egui (the most prominent Rust immediate mode GUI implementation) now, thanks to Matt Campbell's work. I would welcome GPUI and Zed adopting that, and I'm sure Matt can offer help in getting it integrated.
Zed developer here, I've actually looked at how to implement AccessKit in Zed, though I couldn't find a quick way of jumping into it beyond 'read the egui PR' at the time. If anyone wants to take a stab at it I'd love to help out and make it happen :)
Hi, lead AccessKit developer here. Sorry I haven't written much documentation yet. For now, the best way to learn how to use it is indeed to study the egui PR.
It is, Flutter (which also draws all the UI on a canvas) already does that - it’s called AccessibilityBridge. The way it works is they hook into the native accessibility system and create virtual accessibility nodes with the same size and coordinates where the “widgets” are drawn.
I think it’d be useful to create some common AccessibilityBridge-like library since more and more UI frameworks are taking the same approach as Flutter and GPUI.
we absolutely want to make accessibility work – hopefully open source will give us a bit more wiggle room to have folks help us figure some of it out as well.
Worth noting this is an expired draft. Anyone can publish drafts with no vetting. This particular author is also a frequent flyer of nonsensical IETF drafts that make no sense to anyone with a shred of understanding of how the Internet works. Genuinely not worth spending the time to understand, any more than you'd try to read a treatise about how the sky isn't real.
Yeah I was imprecise in the description here, because I started trying to describe how a mechanical movement works and it went into the weeds really quickly :) More accurately, the balance nudges the pallet fork just enough to allow the escapement wheel to advance, and that advancing motion imparts some of the mainspring's force back through the pallet fork and into the balance, so that it continues to oscillate without dampening.
It's a very clever mechanism, and surprisingly subtle. I can't be the only one who first saw a running mechanical watch and thought "wait, isn't that perpetual motion? How does that springy thing keep going without stopping?" Not magic, it turns out, just very very careful engineering :)
Could well be! I have no specialist knowledge, I just got curious about the origin of the fairly random feature name, and went digging. The two well substantiated facts are:
Hacking movements gained popularity between WW1 and WW2 due to army interest (and during WW2 US mil-spec for watches required a hacking feature, leading to e.g. the Elgin A-11 hacking watch).
In the heyday of mechanical marine chronometers (late 18th century through early 20th, roughtly), common use was to set a hack watch to the sheltered ship chronometer, then go above deck with the hack watch to make observations.
The link between these two facts is more tenuous, and basically boils down to: watches with a hacking mechanism would obviously be really handy for marine use, given how the hack watch was used; and military terminology routinely bleeds between the services, so transposition from a navy to an army context around WW2 wouldn't be surprising.
As for why the Royal Navy called these watches hack watches... I pretty much just ran down the dictionary definitions of "hack", including the archaic uses that would have been commonplace in the late 18th century, and made an educated guess. I would hope that there's a book out there somewhere about this era of sailing that has a more substantiated take, but I don't have such a reference myself.
This has nothing to do with watches per se but I was wondering which war movies include soldiers shouting "Hack!" because I can't remember ever hearing it in a film.
There's a sibling thread making the same point, and: yeah, I overgeneralized on that bit. The instance I had in mind was the M.A.S.H. TV show, which has a couple exchanges involving "hack" for time synchronization (unsurprisingly, by the most over the top soldierly characters). All I can offer as a defense is that it was late and I assumed that I couldn't remember others for that reason. But looking around now, film usually goes with the more recognizable "mark".
Reading this writeup, the procedure takes up to two minutes:
* each person in the room pulls up the stem when their individual second hand is pointing at 0, and also sets the time to the prearranged hour/minute,
* then everyone waits a bit longer until this is done;
* after another minute, everyone pushes down the stem simultaneously
Is there an alternative where you could have some way to force your second hand to the 0 position rather than waiting up to a minute for it to get there on its own then freeze it?
I do see why hacking is nice for time zone changes.
There is also a feeling by some horologists and watch fans that the hack interacting with the balance oscillator and suddenly halting its motion is detrimental to the movement's health and precision. I haven't found any data to substantiate this, but I'm told that some watch aficionados prefer non-hacking movements for that reason.
I can imagine this being the case, but the mechanics tend to be so accurate that I could see either being the case. I think the start/stop action is so quick that it likely is not damaging. But I'm clearly not an expert on this.
Another thing - in the comments someone mentioned military folk using hacking watches to sync their watches together. This use case I do know about, although for civilian purposes. We used to do it as kids, and became well aware of just how inaccurate all of our kiddie watches were. We used to sort of race them if our day was long enough. But they were accurate enough for our various games.
It does seem a bit silly to me as well, given the stresses that watch movements are subjected to day to day, and that the hack's mechanical design barely touches the balance at all. It doesn't take very much friction at all to halt these movements, so I struggle to see where the source of damage would lie. But, people have their opinions.
And yeah, mechanical movements are technological marvels, and can keep incredible time for being a completely analog machine... But seconds per day is still about as good as it gets unless you take expensive measures (like the marine chronometers did) to get diminishing returns. And less expensive or well tuned movements can easily drift by a minute or two per day.
In a way, we've been spoiled by quartz and electronic timekeeping. Now that GPS blankets the world and lets any timepiece continuously synchronize to within microseconds, "seconds per day" sounds ludicrous. And yet, it built empires and ran the world for a couple centuries! Especially for civilian use, it's rare to truly _need_ better precision, aside from the general desire for perfection.
