Hi, Disconnect3d - the author here. If you have any questions, I am happy to answer them :).
Readit Newsdisconnect3d commented on When NULL isn't null: mapping memory at 0x0 on Linux disconnect3d.pl//2025/03/... · Posted by u/woodruffw
My personal takeaways from this:
1. Source distribution tarballs that contain code different from what's in the source repository are bad, we should move away from them. The other big supply chan attack (event-stream) also took advantage of something similar.
1a. As a consequence of (1) autogenerated artifacts should always be committed.
2. Autogenerated artifacts that everyone pagedowns over during code reviews is a problem. If you have this type of stuff in your repository also have an automatic test that checks that nobody tampered with it (it will also keep you from having stale autogenerated files in your repository).
3. A corollary of (1) and (2) is that autotools is bad and the autotools culture is bad.
4. Libsystemd is a problem for the ecosystem. People get dismissed as systemd haters for pointing this out but it's big, complicated, has a lot of dependencies and most programs use a tiny fraction of it. Encouraging every service to depend on it for initialization notifications is insane.
5. In general there's a culture that code reuse is always good, that depending on large libraries for small amounts of functionality is good. This is not true, dependencies are maintenance burden and a security risk, this needs to be weighted against the functionality they bring in.
6. Distro maintainers applying substantial patches to packages is a problem, it creates widely used de facto forks for libraries and applications that do not have real maintainers looking at them.
7. We need to make OSS work from the financial point of view for developers. Liblzma and xz-utils probably have tens of millions of install but a single maintainer with mental health problems.
8. This sucks to say, but code reviews and handing off maintainership, at the moment, need to take into account geopolitical considerations.
I would personally add: test your build scripts.
There are so many bugs like the "added dot to disable landlock" added as part of this action (which can also be typos [0]), not to mention that relying on some tools in autoconf to set feature flags will just disable them if those tools are not present [1].
[0] https://twitter.com/disconnect3d_pl/status/17744965092596453...
[1] https://twitter.com/disconnect3d_pl/status/17747470223623252...
disconnect3d commented on The What, Why and How of Containers annwan.me/computers/what-... · Posted by u/ben_s
It's a nice blog post but it still misses a few important building blocks without which it would be trivial to escape a container running as root.
Apart from chroot, cgroups and namespaces, the containers are also build upon:
1) linux capabilities - that split the privileges of a root user into "capabilities" which allows limiting the actions a root user can do (see `man 7 capabilities`, `cat /proc/self/status | grep Cap` or `capsh --decode=a80425fb`)
2) seccomp - which is used to filter syscalls and their arguments that a process can execute. (fwiw Docker renders its seccomp policy based on the capabilities requested by the container)
3) AppArmor (or SELinux, though AppArmor is the default) - a LSM (Linux Security Module) used to limit access to certain paths on the system and syscalls
4) masked paths - container engines bind mounts certain sensitive paths so they can't be read or written to (like /proc/sysrq-trigger, /proc/irq, /proc/kcore etc.)
5) NoNewPrivs flag - while not enabled by default (e.g., in Docker) this prevents the user from gaining more privileges (e.g., suid binaries won't change the uid)
If anyone is interested in reading more about those topics and security of containers, you may want to read a blog post [0] where I dissected a privileged docker escape technique (note: with --privileged, you could just mount the disk device and read/write to it) and slides from a talk [1] I have given which details the Docker container building blocks and shows how we can investigate them etc.
[0] https://blog.trailofbits.com/2019/07/19/understanding-docker...
[1] https://docs.google.com/presentation/d/1tCqmGSOJJzi6ZK7TNhbz...
disconnect3d commented on Modern Python Performance Considerations lwn.net/SubscriberLink/89... · Posted by u/chmaynard
Where can I read about what kind of performance improvements `__slots__` brings?
Apart from the official docs, this video also explains the low level data layout (in CPython) that slots introduce: https://www.youtube.com/watch?v=Iwf17zsDAnY
disconnect3d commented on Debugging with GDB felix-knorr.net/blog/usin... · Posted by u/MarcellusDrum
I haven't seen anyone demonstrate using gdb via CLI in the way you can show off using vim proficiently and have people say "I get it".
In the reverse engineering space there's some folks that use gef. but maybe that's because linux folks dont have olydbg?
would love to see a livestream of someone using gdb in the context of real world engineering. SHOW me the productivity wins here. every article and conference talk about gdb is just handwavey hypotheticals about what you could do, but in practice I just see people moving through basic debugging incredibly slowly
As a CLI power user I can say that I don't think CLI gives much productivity wins over UI/IDE debugging. However, it lets you script things, display things that your IDE wouldn't normally display for you and do some automatic or semi-automatic analysis. Also, as you said indeed there is no ollydbg, or rather x64-dbg equivalent on Linux (which is what people use nowadays on Windows as ollydbg is not developed anymore afaik).
Also even if you use GDB in IDE, you still may need to fall back to the embedded GDB console as e.g. some classes are missing pretty printers or the IDE UI does not allow you to investigate navigate things properly. For example when you have a structure field that is void* and is casted to one or another type depending on the context, it is much easier to use the console to investigate it.
disconnect3d commented on Debugging with GDB felix-knorr.net/blog/usin... · Posted by u/MarcellusDrum
I'll also plug pwndbg[1] here.
Like Gef it greatly extends the utility of GDB, and is oriented around exploit development.
I'll make a shameless plug here as Pwndbg maintainer - apart from the FEATURES.md file describing features, you can see some of them detailed on those slides: https://docs.google.com/presentation/d/1mDfA_27DtLUkOaTZ8U9k...