Hacker News new | ask | show | jobs
by sedatk 14 days ago
Their fix just future-proofs it in case the same bug gets reintroduced.
2 comments

A correct implementation would be to just call glibc directly, this seems like a hasty fix to get the patch out the door. The history of vulns from bad shell escaping is as old as bash, whenever possible you probably shouldn't be mixing code and data, especially in a security critical application like this.
The fact that there is no portable way to link the relevant functions that works reliably across all distributions of Linux is a failure of POSIX and GNU, and unfortunately is largely the Linux distribution story in a nutshell.

Your answer is mostly correct, except that when you tug on that thread the shelf comes off the wall, the plaster comes with it, and then it cracks the water pipes on the way to the floor.

This is just a dirty fix. It adds weird restrictions and masks issues.

Refactoring external invocations to use safe argument handling is a better way to fix it. Along with tests that exercise weird names.

All the hallmarks of an LLM fix right there...
Indeed, but they did have code to use "os/user".Lookup() in a fallback path so I wonder if the issue is that they have some NSS module for user definitions (which wouldn't work with osusergo/static or musl-linked binaries)?

If so, this is kind of an understandably ugly problem, though there is still a better option than shelling out -- systemd-userdb.

I argue the opposite: there’s no better fix for this. You can write the most elegant fix, whatever it is, and prevent that from happening only on the codebase that’s fixed. That doesn’t mean that the codebase will always be the only authority on authentication.

The username policy fixes this issue for good, regardless of whatever you write in the future, or whatever new mechanism is introduced.

It’s a restriction for sure, but it’s not a nonsense restriction? Who would have a username starting with a hyphen? I didn’t even know it was possible until today.

> I argue the opposite: there’s no better fix for this

The better fix would be to not have the username pass through a parser looking for cli flags in the first place.

How do you propose to do that when username is a possible argument?