Yes, liblzma could have used multiple routes to take over sshd. Once you're running inside the process it's game over. The exact details, like how they used ifunc and an audit hook, are very interesting, but ultimately not that important.
$500 isn't worth my time and I don't trust you'd pay up. But for anyone who wants to attempt to get him to pay up, here are three simple approaches:
(A1) In a POSIX constructor function in liblzma, set an alarm(2) for a few seconds later (once sshd has fully loaded).
(A2) In the alarm callback locate the original function that was patched using dlfcn, and mmap a page of modified code over the top that calls the exploit.
Or:
(B1) POSIX constructor function, call clone(2) to start a background thread.
(B2) In the background thread, sleep for a little, then patch the code as in A2 above.
Or:
(C1) POSIX constructor function that completely replaces the sshd process with a workalike that contains the exploit.
In A & B, for OSes (not Linux) that deny mmap, you'll need to find a struct or stack frame used by the function and work out how to adjust the data it uses or find a function pointer and exploit that.
You may well be right about this! What I genuinely don't understand then, is why Jia Tan relied on ifunc rather than POSIX constructors. Seems like that would have been easier and more widely applicable, right?
His team used ifunc because it made the attack less obvious if you are running sshd under strace. An alarm or clone system call in strace would stick out a mile, even if the code executing the syscall was obfuscated.
So it's clever to use ifunc, but not necessary for an attack to work.
Likely the existing toolkit they seem to have been using had primitives for this already, but as I said in the Veritasium video I appreciate that this was a very sophisticated attack executed by a smart team.
It is weird to limit to "the same attack". Why does it even have to be the same attack? From the moment sshd loads your modified lib, you're literally running code with root privileges on the victim machine. You can literally run _any_ attack you wanted, with zero persistence. This is worse than a OpenSSH RCE.
Even in your own talk you basically admit this, so what are you doing here? If you think there's something here that everyone is missing but you don't, why not actually explain what it is?
I don't have any secret information! Folks were giving me a hard time about claiming that ifunc is central to this attack, and I would genuinely find it valuable to know that Jia Tan could have (for example) performed this attack against a musl-based distro.
You can always populate .init_array section with a hidden constructor. It would work just like ifunc and would always execute at shared library load time.
I think .init_array is too late in the game. ifunc lets you hijack the loader, because it is sort of like a plugin or dynamic config for the loader itself. Everything should be loaded and resolved by the point that .init_array stuff starts getting triggered, though ELF is dark and full of terrors so who knows really.
No it's not. You exposed that data to an LLM. Should have read the fine print. The laws around that don't make sense to me anymore so therefore I own that stuff now. That's how this works right? You do know chatgpt etc can read everything you write, right?
Also social media profile pics. Great way to get faces for deep fake ads. Most people are just 1 phone call away from being voice cloned. Our likeness isn't all that important either if you think about it.
Maybe meta will clone your writing style and sign into your meta account and message your friends telling them about this awesome new product. Meta owns the account and you uploaded data to it.
I think Anthorpic has pledged to not use team and enterprise user's data for training purposes. I don't mind if they do some verification or whatever as long as it doesn't end up in the responses it gives others.
For the old version support. Why not do some compile time #ifdef SUPPORT_ES3? That way library writers can support it and if the user doesn't need it they can disable it at compile time and all the legacy code will be removed
> Why not do some compile time #ifdef SUPPORT_ES3?
Rather unfortunately, JS has no native precompiler. For the SQLite project we wrote our own preprocessor to deal with precisely that type of thing (not _specifically_ that thing, but filtering code based on, e.g., whether it's vanilla, ESM, or "bunlder-friendly" (which can't use dynamically-generated strings because of castrated tooling)).
Two problems:
- people would need to know how to effectively include dependencies in a way that allows them to be tree shaken, that's a fragile setup
- polyfills often have quirks and extra behaviours (eg. the extra functions on early promise libraries come to mind ) that they start relying on, making the switch to build-in not so easy
Also, how is this going to look over time with multiple ES versions?
> people would need to know how to effectively include dependencies in a way that allows them to be tree shaken
Is the need for tree-shaking not 100% a side-effect of dependency-mania? Does it not completely disappear once one has ones dependencies reduced to their absolute minimum?
Maybe i'm misunderstanding what tree-shaking is really for.
It doesn't bypass it exactly, it's still accessing it via virtual memory and the page tables. It's just that the kernel maintains one big linear memory map of RAM that's writable.
Half the time when people say they're using telnet (including in this thread) they're really just using the client as a TCP client, not doing anything with the Telnet protocol.
No one is stopping you from using the telnet client. And really you should just use netcat
There's one thing I haven't figured out with netcat- how do you know it connected? (I just looked it up, after many years: the -v flag. Which makes sense because netcat is supposed to be "transparent").
To maximize device performance when wiping a drive to use for something else, I use nvme format with --ses=1.
Which in theory should free all of the blocks on the flash.
Really hard to find good documentation on this stuff. Doesn't help that 95% of internet articles just say "overwrite with zeroes" which is useless advice
What's the difference between this and sanitize? Should we be doing both?
[edit] sanitize runs on the controller level while format works on the namespace level. So I suppose formatting won't touch any pages not allocated to a namespace.
I wish there was _any_ way to find out which NVME controllers supported which operation before you buy them!
Anything that works at the logical block interface will not usefully wipe the device. SES 1 will physically hit every erase block on the device with 20V to blow it away. This happens suspiciously quickly (< 60 seconds typically) but that's just because flash is great.
It consumes one of the erase cycles, of which a device has a few hundred or maybe a few thousand over its lifetime. It's not something you'd want to do frequently.
This is broadly true of cheap thumb drives, but not true of all USB flash drives. The larger ones generally do support secure erase. E.g. the Crucial X6. I don't know if these use secret vendor commands, or if they use the standard SCSI "sanitize" command.
That doesn't work on any* NAND flash device, be it a flash drive, NVME, SATA, whatever.
The block device you see is an abstraction provided by the SSD controller. In reality, the flash capacity is larger. Pages are swapped out for wear leveling. If a block goes bad, it'll be taken out of commission, and your data may hide in there.
All of this happens on the SSD controller. The kernel doesn't know. You have no way to directly erase or modify specific blocks.
*Okay, there are raw NAND flash chips without controllers, but that is not you're working with when you have a SSD or flash drive. If you do have a raw flash chip, you can more directly control flash contents.
This is what `shred` and other secure wipes do. There is some concern over data stored in sections which the firmware has swapped out and made inaccessible. But if this is a concern to you, then you should be using full disk encryption anyway which makes all of this a non issue.
