Asked on the mailing list: https://lists.gnu.org/archive/html/bug-hurd/2021-05/msg00079.html
(Would be fun if they reply that this vulnerability is well known, and I'm the 100th person to post about it. We'll see.)
How does this even work?
How do you fix a vulnerability in an open source (*) project with low commit activity (**) without immediately giving out where the vulnerability was?
Anyone has any ideas?
(*) in this case, I actually mean "open source", not "Free Software"
(**) so sneaking in a "totally fix a minor typo in a comment" in between thousands of other commits wouldn't work
Update: I've now developed (rough, WIP) patches fixing the first two vulnerabilities. (Haven't even started thinking about how the 3rd one could be fixed.)
The patches touch a lot of code, but seem to work fairly well. It's almost as satisfying to see my exploits not work as it has been to see them work 😀
Well, it feels as if I have rewritten like half of the Hurd (with additional patches for glibc and GNU Mach...), but I finally have developed the patchset to thoroughly fix all three of my vulnerabilities. 🎉
And the patches are no longer "very WIP", they're nice & relatively self-contained, and they ended up less intrusive than it seemed they had to be.
Bad (?) news: I found many more issues that seem exploitable. Some of them I already fixed; others would need more work.
@meisam I've done that, yeah. But it doesn't seem like they have a process for this in place either, hence me asking.
@bugaevc Develop a fix in private, get a review in private, coordinate with downstream maintainers in private, then do simultaneous release.
Don't forget to request a CVE for this, I'm told it helps with pushing the update through queues in distributions. Say, Debian is frozen at the moment, I'm not sure if even a CVE will be enough to consider the vulnerability a release-critical bug.
Also, CVEs might take like a week or two to get assigned, so start on it early.
My creds: I handled two CVEs as a maintainer of Newsbeuter, and the above is what I did. Hiding the fix in between other work wasn't an option (long story).
@bugaevc You can attempt to obfuscate it by having a private repo that lives just ahead of your public one, build your release from that, and sync them back up at some point after the release has had time to disseminate.
There's danger there still, of course, two release trees can be compared for difference, so it really only makes it marginally harder to spot the change, it doesn't actually prevent detection.
@saramg hmm, I bet most Hurd boxes are running Debian GNU/Hurd, so potentially it would be enough to convince Debian to ship a package with a fix, without waiting for an upstream release.
But then Debian also ships debug sources. Hmm.
@bugaevc In general, I think you're doing this right™. You contacted the maintainers and asked for a means to disclose in private and are generally waiting on them to define how the public disclosure happens. They've replied, so the process is working as designed.
@bugaevc Hi, yes please get in touch with the Debian Hurd maintainers (yes, some are still active). CVE filing is important, visit cve-mitre.org. If you don't hear back from people in Debian, ping me here or on IRC (OFTC, Freenode, nick: sunweaver).
I am somewhat in touch with Samuel Thibault now. It sounds like if I do the fixes, Samuel will be able to roll the patched packages out in Debian Hurd before we release the details to the public.
Amos Jeffries of Squid Proxy has generously offered to help me with filing CVEs.
Sounds like things are on the right track, except I haven't heard from them for two days now. If I continue not hearing from them, I'll ping you. Thanks!
@bugaevc Debian people are currently in release freeze for Debian 11, so everyone is a little more busy than usual.
@js but that's the thing, how can you be sure nobody's using it?
It's an official GNU project, and it's been out there for a long long time. People who run it don't have to report to me (or anyone) that they're running it.
I myself, for quite some time, was just poking the Hurd without even posting about it here. Now sure, in my case it's a VM and not a production server, but still, I don't feel I can randomly screw people over like that.
@bugaevc I think HURD is nowhere ready for production, so anyone using it in production has only themself to blame ;)
@js if it wasn't for, well, me, how's it not ready for production? 😀
Stuff's missing and Linux is way ahead, but does that mean you can't host your sever on Hurd?
@bugaevc You can. But then don’t be surprised if you get pwned ;). If you could easily find it, someone else can too. This is shown by the fact that you didn’t find one bug, but multiple. Just showing nobody even bothered to look so far ;). I by no means want to diminish your accomplishment of finding them, but it still points to HURD not being ready IMO.
This Mastodon instance is for people interested in technology. Discussions aren't limited to technology, because tech folks shouldn't be limited to technology either!