-
-
Notifications
You must be signed in to change notification settings - Fork 3.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
resolved: various monitor fixes #24853
Conversation
|
This should address all remaining issues I see with #22845 |
d1f1100
to
507bbae
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not a big fan of removing the config flag, but ok. But this needs test updates - new helpers need unit tests, and TEST-75 needs adjustments and coverage for the monitor command.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks nice. I didn't review the monitor output in detail. @surajkrishnan14 can you review those parts to make sure that the output looks OK?
|
This will need another round of reviews after all the comments… |
507bbae
to
7590aaa
Compare
This is still unaddressed, and tests are failing because of it |
7590aaa
to
fd099bb
Compare
Now addressed. PTAL. |
|
I also added some better support for following CNAME chains: each element in the chain will show up as a separate query. But each query will also contain the questions of previous elements of the chain in a new |
|
|
grr, this is UndefinedBehaviorSanitizer being stupid here... will add work-around |
|
I've just reported the first remote DOS with the monitor enabled: #25449. |
|
FWIW it's going to get its CVE in a couple of days I think. Technically there should be two CVEs because there are two different codepaths that can lead to the crash but I don't think it matters much in this particular case. |
|
There is no need for any CVE, given it requires local root access to reproduce, a bug report is more than enough |
|
It requires local root access to subscribe to the notifications. Once there is at least one subscriber |
|
Local root access is a necessary prerequisite, hence "can be crashed remotely" is completely nonsensical, as anything including ssh fits into that definition |
By this logic resolved can never be crashed remotely because |
|
No, resolved is enabled by default in many distros and images |
|
Let me get this right if resolved on one machine with at least one subscriber can be crashed by resource records coming from remote servers it's actually just a local crash that requires admin privileges? |
There are zero subscribers for this debug tool by default, adding one requires real-time local root access, hence this is at best a minor bug causing a local crash, and even that's a stretch |
Right and nobody is saying that there are more than zero subscribers by default. It affects only machines where this feature is actually used and they can be crashed by resource records coming from remote machines. |
|
Which makes it a minor bug at best, but most definitely not worth of wasting anybody's time with a cve, because the security significance is non-existent given it requires real-time root access |
Well, by this logic #23873 (where Anyway I get what you are saying. It seems that by that logic only stuff like #19584 can be considered a remote DOS. |
|
I sent a link to this thread. It should be added to the description eventually. |
|
Sent to whom? What description? |
MITRE
The place where references to bugs are placed. |
|
Are you aware of the process defined at https://github.com/systemd/systemd/security/policy ? |
|
I'm aware of that. |
|
And you decided to ignore it and bypass it because...? |
|
It's a long story but if you haven't noticed I always report systemd bugs like that publicly. I think it started when I was told that fuzzing stuff shouldn't be sent to that mailing list for some reason. I didn't think it was a good idea but basically when I opened PRs like #10200 all those overflows were immediately public. I didn't request CVEs though because at the time I was able to backport those fixes without that. |
|
Bugs like #19584 are already public so there is nothing to coordinate anymore. |
|
Opening github bug reports for issues of any kind is one thing, and most of the times it's fine to do so, especially for the fuzzing stuff. Contacting MITRE to ask for a CVE to be assigned, bypassing the established security process and without consulting anybody else, is very much a different matter altogether. |
Fuzzing stuff is exactly what should be covered by the security process. When infinite loops like 86b06c6 can be triggered in dhcp-client on receiving some weird packets it should go through that process. And if projects agree I of course participate in CVD.
Well, what else should I do? Let's revisit the policy of not sending fuzzing stuff to that mailing list. I would be more than happy. |
|
|
I did contact MITRE and sent links to this thread and #25518 a few hours ago and for now "NOTE: there is some debate about the security relevance of this report because there are zero subscribers by default." ended up in some other CVE. I think it should be fixed soon. I also put use-after-frees, infinite loops and stuff like that that can be triggered remotely on hold because based on #25518 (comment) it seems if a feature like |
Having thought about it a bit more I think I'm just going to keep reporting issues publicly but instead of vague bug reports like #22480 I'm just going to be more specific. In that particular case there is a reachable assertion in systemd-resolved that can be triggered by any local user by writing crafted messages to that world-writable socket. Restart doesn't help much obviously because it can be wrapped in a loop (and I frankly have no idea why so much trust is put in "restart" because if stuff is crashed fast enough it gets rate-limited by systemd https://www.freedesktop.org/software/systemd/man/systemd.unit.html#StartLimitIntervalSec=interval). I've just checked and Debian Stable still ships resolved where that and a bunch of other local and not-so-local issues are present. The actual Debian security team tracks issues like that (for example avahi/avahi#338). I'm a bit conflicted about being specific about how to trigger various memory corruptions but my understanding is that it should be fine because apparently by the systemd security logic to trigger something in, say, dhcp-server root should enable it somehow so in the end it's downplayed to something requiring user-interaction with the highest privileges so there should be no harm in full public disclosure. |
Let's trick out UndefinedBehaviourSanitizer: systemd/systemd#24853 (comment)
No description provided.