Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

GhostLock, a stack-UAF that has existed in all Linux distributions for 15 years

nebusec.ai

Post reply on HN
Print view View original

161–170 of 209 posts

Re: GhostLock, a stack-UAF that has existed in all Linux distributions for 15 years

#161

Post by titularcomment »

NexRebular wrote: post #160
titularcomment wrote: post #102

Earlier quoted context omitted.

OpenBSD is the Linux of a decade or two ago, not attracting attention and not being compatible or useful for quite a lot of stuff.

Not counting GPU compute, what exactly is OpenBSD not useful for?

Personal laptop use with Ada Lovelace or Ampere family NVIDIA GPUs (did you mean this or CUDA, i couldnt tell), personal desktop use with unusual peripherals, dependency on ports, existence and competition of FreeBSD etc. I love OpenBSD's code philosophy (they were the first to introduce a lot of security techniques[1]) and the programs they produce, OpenSSH is a lifesaver, and I use doas for its low footprint on my Linux machine. Still, they have a convulated install process, dubious hardware and software compatibility that is better solved in the Linux world today.

[1]: https://www.openbsd.org/innovations.html

Re: GhostLock, a stack-UAF that has existed in all Linux distributions for 15 years

#162

Post by treyd »

ChocolateGod wrote: post #134
kuschku wrote: post #122

Earlier quoted context omitted.

Once upon a time(tm), Google had a great solution for that: You could get a credit card in nano SIM format, and insert into in your dual-SIM phone. That then allows you to do secure NFC credit card payments even on a rooted phone with custom ROM.

That doesn't work when someone has multiple or virtual cards. That also means if someone steals my phone they get my credit card too. Not a great solution.

You can load multiple card identities onto the same SIM and select the one you want to use.

Re: GhostLock, a stack-UAF that has existed in all Linux distributions for 15 years

#163

Post by treyd »

alexjplant wrote: post #26

> This is the same shape as many other life-cycle bugs [...] Claude-ism detected. IME with Claude Code an object does not have a type or definition, apparently, but rather a shape (or at least it reaches for that word before more technically-accurate ones). Problems are not of a similar class or type, but of the same shape. Functions are not defined by their signatures but by their shape. Who talks like this and how…

I've used phrasing like this from time to time before, like when trying to compare two ideas that are unalike but have some fuzzy similarities. I wouldn't use it to describe functions but "problems", "solutions", and other fuzzy things.

Re: GhostLock, a stack-UAF that has existed in all Linux distributions for 15 years

#164

Post by otterley »

dang wrote: post #78
otterley wrote: post #73

Earlier quoted context omitted.

Non native speakers have been on HN since its inception. Unless you mean something else?

Sorry, I was posting hastily and can see how that was unclear. Unfortunately I've forgotten my point. Perhaps it was this: there are many non-native English speakers who have valuable things to contribute to HN, who don't yet have sufficient English or don't feel they do, and therefore resort to LLMs to do their English for them. Should they automatically be excluded?

You said earlier that we don't allow LLM-generated content on HN itself (i.e., the comments). So, at least in principle, that's already taken care of through exclusion.

If you mean the linked content: can come from anyone and anywhere--it's just whatever someone submits and is deemed good enough by The Algorithm to get attention. So that's not "HN content" - the content exists independently of HN. As for that, I'll repeat myself: the scientific community has managed somehow to intercommunicate for centuries despite language barriers before LLMs existed. (English was neither Einstein's nor Madame Curie's first language.) It's an existence proof that LLMs aren't needed to overcome those barriers.

Re: GhostLock, a stack-UAF that has existed in all Linux distributions for 15 years

#165

Post by ptx »

inigyou wrote: post #154
insanitybit wrote: post #146

Earlier quoted context omitted.

That's right. Docker still runs without user namespaces by default, which means that root is the same user inside and outside of the container. This does open up attack surface and configuration footguns. Confinement still leverages dropping some root caps, seccomp, various other namespaces, etc.

I don't think this is true, otherwise you could just load a kernel module into the host kernel from a container.

Presumably Docker's seccomp profile [1] blocks the init_module system call which is used by insmod [2]. Although, looking at the default profile, it seems to explicitly allow it - but maybe only if you have CAP_SYS_MODULE, which I think means running Docker with "--cap-add=SYS_MODULE".

[1] https://docs.docker.com/engine/security/seccomp/

[2] https://tldp.org/HOWTO/Module-HOWTO/x627.html

Re: GhostLock, a stack-UAF that has existed in all Linux distributions for 15 years

#166

Post by tptacek »

inigyou wrote: post #129
tptacek wrote: post #9

Earlier quoted context omitted.

That's a huge amount of money for a vulnerability.

Also one order of magnitude less than you could get on the black market for a universal Linux LPE and two orders less if you can make it work reliably.

I believe you are two orders of magnitude wrong, in the upward direction, on that number (the first of them). You're talking about reliable remote numbers there, full chain, full enablement, tranched with maintenance.

Re: GhostLock, a stack-UAF that has existed in all Linux distributions for 15 years

#167

Post by tjoff »

physicalecon wrote: post #158
inigyou wrote: post #154

Earlier quoted context omitted.

I don't think this is true, otherwise you could just load a kernel module into the host kernel from a container.

It is very possible to load a kernel module into the host from a container. https://stackoverflow.com/questions/33013539/docker-loading-...

FYI, looks like you are shadowbanned.

Re: GhostLock, a stack-UAF that has existed in all Linux distributions for 15 years

#168

Post by dji4321234 »

mschuster91 wrote: post #109
coffe2mug wrote: post #81

Earlier quoted context omitted.

Would be amazing if this was used to root so-far unrootable android devices. Any suggestions.

Wonder if it were possible to use this to (finally) jailbreak DJIs original RC that came with the Mini 3 Pro. It doesn't have a web browser or, virtually, anything of use... but I think it supports enough of a web browser to log in into wifi captive portals.

Root for these RCs has been available under the guise of “FCC hack” for a really long time now; different groups have different exploits (it’s DJI so there are plenty) that work on different firmware versions.

This would almost surely work there too, though.

Re: GhostLock, a stack-UAF that has existed in all Linux distributions for 15 years

#169

Post by dji4321234 »

amarcheschi wrote: post #150
mschuster91 wrote: post #109

Earlier quoted context omitted.

Wonder if it were possible to use this to (finally) jailbreak DJIs original RC that came with the Mini 3 Pro. It doesn't have a web browser or, virtually, anything of use... but I think it supports enough of a web browser to log in into wifi captive portals.

What can you do with a jailbroken drone rc?

Mostly they’re used to enable illegal RF parameters in Europe (FCC hack); DJI disabled strict geofencing in most of the “west” several years ago and that was also enforced in the drone anyway.

Re: GhostLock, a stack-UAF that has existed in all Linux distributions for 15 years

#170

Post by dboreham »

chlorion wrote: post #131
maple3142 wrote: post #115

Earlier quoted context omitted.

If you are given a shell with `docker run -it --rm alpine:3 sh`, can you read the /etc/shadow on the host without kernel exploit? Assuming the docker and kernel are sufficiently update-to-date (e.g. latest Docker on Debian Stable).

No. The "root" you get in docker is not actually root outside of the namespace the container in running in. Assuming no bugs in the kernel, it should not be able to do anything more than the UID that it's mapped from.

Hmm. Either I've lost my mind, or you're running a different Docker than me, or you're thinking of some strange scenario such as a Mac where docker is actually inside a VM, or you're wrong.

While there is a feature to do with UID mapping, it doesn't actually work/isn't usable/nobody uses it in current docker iirc.

Therefore root in the container very much is root on the host.

Post reply on HN