| Summary: | dbus generated notifications display images without imposing a size limit | ||
|---|---|---|---|
| Product: | [Plasma] plasmashell | Reporter: | postix <postix> |
| Component: | Notifications | Assignee: | Plasma Bugs List <plasma-bugs-null> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | kde, kde, nate |
| Priority: | NOR | ||
| Version First Reported In: | 6.4.1 | ||
| Target Milestone: | 1.0 | ||
| Platform: | Other | ||
| OS: | Linux | ||
| Latest Commit: | https://invent.kde.org/plasma/plasma-workspace/-/commit/b91489b1628fed1efc242ed5524253176d461d39 | Version Fixed In: | 6.4.6 |
| Sentry Crash Report: | |||
|
Description
postix
2025-07-09 10:41:26 UTC
Rendering some tags is defined expected behaviour. See https://specifications.freedesktop.org/notification-spec/1.3/markup.html We escape other tags, we don't allow arbitrary HTML injection. As far as I am aware we are compliant with that spec, please let me know if not. The issue with opening /dev/urandom is indeed valid. > Rendering some tags is defined expected behaviour. See > https://specifications.freedesktop.org/notification-spec/1.3/markup.html > We escape other tags, we don't allow arbitrary HTML injection. That's great, I will rephrase the title. ---- > As far as I am aware we are compliant with that spec, please let me know if not. I think GLib maintainer Philip Withnall has posted a qualified answer https://gitlab.gnome.org/GNOME/glib/-/issues/3720#note_2491853 > Fundamentally I think this is a problem with the xdg notification specification: > * In the top-level ‘Markup’ section it says the notification server should filter out > markup tags if it doesn’t support them, which suggests the client > should be able to unconditionally send markup. > * In the capabilities table, however, it says that the client > should strip out markup if the server doesn’t advertise the body-markup capability. > Those two statements are slightly contradictory, > although it would be possible to get them both to work. > (...) I guess body-markup is advertised and therefor clients are free to unconditionally send markup in case of Plasma, correct? ---- > The issue with opening /dev/urandom is indeed valid. Quoting from above mentioned comment: > If a server implementation reads an image without imposing some kind of size limit on what it reads, > that’s a server bug. Yes, this is then hopefully the only real threat here. A possibly relevant merge request was started @ https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/5667 Git commit fe2d07b21403d20202514a5e5860698d52610da3 by David Edmundson. Committed on 23/09/2025 at 12:50. Pushed by davidedmundson into branch 'master'. Sanitize images in notifications Notifications are allowed to show local URLs. It's possible to break plasma by loading an image with a URL of file:///dev/urandom. This could be sent from a remote source; applications emitting notifications should sanitize their input, but we shouldn't solely rely on that. This adds a few extra checks that the image is a valid local file. Timing attacks are still possible, but only with locally running code, so not something to be concerned with. M +20 -3 libnotificationmanager/autotests/notifications_test.cpp M +21 -1 libnotificationmanager/notification.cpp https://invent.kde.org/plasma/plasma-workspace/-/commit/fe2d07b21403d20202514a5e5860698d52610da3 Git commit b21323c647ef263b150096965ca4ab934b32aa0b by Nate Graham, on behalf of David Edmundson. Committed on 26/09/2025 at 20:44. Pushed by ngraham into branch 'Plasma/6.5'. Sanitize images in notifications Notifications are allowed to show local URLs. It's possible to break plasma by loading an image with a URL of file:///dev/urandom. This could be sent from a remote source; applications emitting notifications should sanitize their input, but we shouldn't solely rely on that. This adds a few extra checks that the image is a valid local file. Timing attacks are still possible, but only with locally running code, so not something to be concerned with. (cherry picked from commit fe2d07b21403d20202514a5e5860698d52610da3) 3cd7bb2f Sanitize images in notifications Co-authored-by: David Edmundson <kde@davidedmundson.co.uk> M +20 -3 libnotificationmanager/autotests/notifications_test.cpp M +21 -1 libnotificationmanager/notification.cpp https://invent.kde.org/plasma/plasma-workspace/-/commit/b21323c647ef263b150096965ca4ab934b32aa0b Git commit b91489b1628fed1efc242ed5524253176d461d39 by David Edmundson, on behalf of Nate Graham. Committed on 29/09/2025 at 15:12. Pushed by ngraham into branch 'Plasma/6.4'. Sanitize images in notifications Notifications are allowed to show local URLs. It's possible to break plasma by loading an image with a URL of file:///dev/urandom. This could be sent from a remote source; applications emitting notifications should sanitize their input, but we shouldn't solely rely on that. This adds a few extra checks that the image is a valid local file. Timing attacks are still possible, but only with locally running code, so not something to be concerned with. (cherry picked from commit fe2d07b21403d20202514a5e5860698d52610da3) 3cd7bb2f Sanitize images in notifications Co-authored-by: David Edmundson <kde@davidedmundson.co.uk> M +20 -3 libnotificationmanager/autotests/notifications_test.cpp M +21 -1 libnotificationmanager/notification.cpp https://invent.kde.org/plasma/plasma-workspace/-/commit/b91489b1628fed1efc242ed5524253176d461d39 |