Catanzaro: Dangerous arbitrary file read vulnerability in Yelp [LWN.net]

GNOME contributor Michael Catanzaro has written a blog post about a noteworthy vulnerability in GNOME's help browser, Yelp.

I don't normally blog about particular CVEs, but Yelp CVE-2025-3155 is noteworthy because it is quite severe, public for several weeks now, and not yet fixed upstream. In short, help files can read your filesystem and execute arbitrary JavaScript code, allowing an attacker to exfiltrate any files your Unix user has access to.

The vulnerability was first reported on December 25, and it was made public on March 26 after the 90-day-disclosure deadline was reached. Patches have been proposed to fix the issue. The bug reporter has published a writeup demonstrating the attack. Catanzaro asks that Linux vendors "please consider applying the provided patches even though they have not yet been accepted upstream".

to post comments

Script inside SVG?

Posted Apr 16, 2025 19:16 UTC (Wed) by epa (subscriber, #39769) [Link] (16 responses)

allowing us to use a <script> tag in a <svg> tag to inject arbitrary scripts.

Yikes, SVG can contain JavaScript? I'm sure this seemed like a good idea at the time and there might even, perhaps, be a legtimate use for it somewhere. But it seems like the kind of thing that should be disabled by default (in fact, I would say a help browser using HTML should have all JavaScript disabled). That would have blocked this exploit.

Script inside SVG?

Posted Apr 16, 2025 21:13 UTC (Wed) by excors (subscriber, #95769) [Link] (13 responses)

I think the original idea was for SVG to be part of a system for interactive graphical applications on the web, competing with Flash. That requires scripting, and it made sense to integrate SVG with existing web technologies - JS, DOM, CSS, XML, XHTML, etc - rather than duplicate all that work. Even if there was no <svg:script>, with XML Namespaces and <foreignObject> you can put JS in XHTML in SVG in XHTML and modern browsers will execute it; the W3C wanted all their XML-based technologies to integrate like that.

It turned out nobody wanted to write interactive graphical applications using SVG, so it has just hung around as an overly-complex inefficient vector graphics file format, causing occasional problems when someone remembers its real capabilities.

Web browsers do disable scripting etc when you use <img src="example.svg">, so its security considerations in the <img> context are basically the same as JPEG, i.e. it's pretty safe. But it sounds like Yelp was using XSLT to transform a custom XML language into HTML, and that just copied SVG elements verbatim without any kind of allowlisting, which is about as dangerous as copying untrusted HTML verbatim.

Based on a cursory look at the code, I suspect Yelp may be equally vulnerable to script injection via MathML - it seems to copy those in the same way as it does SVG, and you can put:

<annotation-xml encoding="text/html"><script xmlns="http://www.w3.org/1999/xhtml">...

inside MathML and browsers will execute it (in both XML and HTML parsing modes; XML only needs the xmlns, HTML only needs the annotation-xml). So this is not really SVG's fault.

<script>s get executed in inline SVG

Posted Apr 16, 2025 23:15 UTC (Wed) by CChittleborough (subscriber, #60775) [Link]

I just tried the example from the SVG standard's specification of <script>, and it ran in the latest Firefox and Chrome. So I created a little HTML file containing that SVG, and the JavaScript still runs.

So <img src="example.svg"> is safe, but inline SVG will execute any <script> elements, including event handlers such as onload= attributes.

This is not relevant to the yelp problem, but is something more for long-suffering web developers to keep in mind ...

Script inside SVG?

Posted Apr 17, 2025 6:41 UTC (Thu) by epa (subscriber, #39769) [Link] (7 responses)

In my view copying HTML verbatim should not be dangerous *in a help browser*. Whatever it does with the HTML should involve displaying it, not executing any scripts.

It can check the HTML too, making sure it doesn't have <script> elements, to present a useful error message -- but that shouldn't be the only defence. The writeup notes: "Simply appending a script tag or a malicious on* attribute in the input XML document won't work since handling these tags is not defined in the yelp-xsl app." Which is great, but an oversight in the XSL processing shouldn't open the door to arbitrary scripting.

I think WebKitGtk needs a mode without any JavaScript support, and this should even be the default (since there are hundreds of little programs that just want to display some HTML in their splash screen or help text with a few lines of code, while writing a web browser is a less common task).

SVG mode needs to be SVG Tiny Portable/Secure

Posted Apr 17, 2025 9:35 UTC (Thu) by johnjones (guest, #5462) [Link]

the whole point is you can have a logo or drawing to explain but you dont need scripts and

https://datatracker.ietf.org/doc/html/draft-svg-tiny-ps-a...

Script inside SVG?

Posted Apr 17, 2025 9:40 UTC (Thu) by excors (subscriber, #95769) [Link] (4 responses)

One comment in the bug report says "We do use JavaScript in the HTML output for things like expandable sections. Disabling all JavaScript would break numerous features". It also uses MathJax for MathML rendering; apparently WebKit has reasonable native support for MathML nowadays, but not back in 2012 when Yelp added it. And it looks like there's highlight.js for syntax highlighting.

If WebKitGTK had a no-scripting mode, Yelp would probably have disabled that mode because scripting is very useful.

Script inside SVG?

Posted Apr 17, 2025 10:51 UTC (Thu) by epa (subscriber, #39769) [Link] (1 responses)

I wonder about a mode that lets pages load external Javascript from a single, fixed directory, but forbids or severely restricts inline <script> elements.

Script inside SVG?

Posted Apr 17, 2025 12:13 UTC (Thu) by excors (subscriber, #95769) [Link]

Sounds like you want Content Security Policy (https://developer.mozilla.org/en-US/docs/Web/HTTP/Guides/CSP), where a page's HTTP header or <meta> element can restrict the page to only load scripts from a specific origin (domain), disable inline scripts and event handlers, only allow scripts with specific hashes, only allow <script>s with a server-generated nonce (which is what the Yelp patch does), etc.

It's explicitly "not intended as a first line of defense against content injection vulnerabilities" but it "reduces the harm that a malicious injection can cause" (https://www.w3.org/TR/CSP3/)

Script inside SVG?

Posted Apr 21, 2025 23:55 UTC (Mon) by NYKevin (subscriber, #129325) [Link]

You don't need JavaScript for expandable sections, that's just <details>. You probably do need some JavaScript for other forms of basic DOM manipulation (like syntax highlighting), but you almost certainly do not need it to have internet access (we're displaying help files from the local system, not the internet). The "obvious" solution is to dump Yelp inside of a Flatpak (or any Flatpak-like thing, like a Nix container, a Docker image, etc.), turn off its internet access, and call it a day. But that would be unacceptable to every distro that packages GNOME, so it will probably not be done as the official upstream fix (as entertaining as it might be to watch 50 different distros grapple with "you can't un-Flatpak it for security reasons" versus "you can't keep it in a Flatpak because Flatpak is evil").

I imagine there might be some cases where you try to load a Yelp document over HTTP(S) for legitimate reasons (e.g. because the help file is not installed locally), but I really hope that is not the case because Yelp is unmaintained (per the bug tracker) and should not be dealing with untrusted content from the internet. If they are not already planning to remove its internet capabilities outright, they should do that now.

Script inside SVG?

Posted Apr 23, 2025 6:20 UTC (Wed) by mathstuf (subscriber, #69389) [Link]

AFAIK, WebKitGTK does support disabling JS: https://github.com/uzbl/uzbl/blob/master/src/variables.c#...

Script inside SVG?

Posted Apr 17, 2025 13:18 UTC (Thu) by mcatanzaro (subscriber, #93033) [Link]

There are two options to disable JavaScript: WebKitSettings:enable-javascript, which is a heavy hammer to turn it off completely, which applications often cannot use because they generally need to be able to run their own JavaScript, and also WebKitSettings:enable-javascript-markup, which disables all JavaScript embedded in documents but still allows applications to execute JavaScript themselves. WebKitSettings:enable-javascript-markup is generally what you want.

However, it seems Yelp does need to allow documents to execute certain approved scripts, so I guess it can't use either of these.

Script inside SVG?

Posted Apr 17, 2025 16:51 UTC (Thu) by sfeam (subscriber, #2841) [Link] (3 responses)

I have nothing to say about yelp per se. However I think you and the parent comment are underestimating the usefulness of SVG as a component of help files or browser-accessible documentation.

For example here is an on-line copy of gnuplot's User Manual . It uses svg for the figures (drill down through the sections under "plotting styles"). These particular figures are not interactive; they are embedded as you suggest with the tag <img src="example.svg">. However the corresponding demo pages, for example 2D hypertext demo and 3D hypertext demo are interactive, with the express purpose of showing how javascript can be used in conjunction with the pre-generated figures to allow a subset of the additional power to explore the data that you could get in a true interactive session.

Script inside SVG?

Posted Apr 17, 2025 18:30 UTC (Thu) by excors (subscriber, #95769) [Link] (2 responses)

You don't need SVG for that though, you can use HTML <canvas> + JS instead: https://gnuplot.sourceforge.net/demo_canvas_6.1/hypertext...

On plots with a large number of data points, SVG has noticeably poor performance - e.g. https://gnuplot.sourceforge.net/demo_svg_6.1/isosurface.html (SVG) takes over a second to render on my PC, whereas https://gnuplot.sourceforge.net/demo_canvas_6.1/isosurfac... (canvas) renders 10x faster (according to Firefox's profiler). DOM and CSS are a very inefficient way to draw ten thousand dots and lines.

I agree that interactive graphics are very useful in documentation and on the web, so I didn't mean to dismiss that use case - I just think SVG is generally a poor technology for that and there are better options.

(I suspect the fundamental issue is that interactive SVG is a retained-mode graphics API, and there's no way to make one of those that is universal, because applications have such widely varying requirements. Some want automatic hit-testing of every shape in the scene, others want to draw a million little dots; some want to animate a few parameters, others want to completely change the entire scene from one frame to the next; etc. You can't satisfy them all with the same API and the same graphics architecture.

But you can satisfy most of them with a lower-level immediate-mode graphics API, like <canvas> or WebGL, plus a range of scene graph libraries (third-party or application-specific) on top of that, so developers can choose appropriate tradeoffs between features and performance and complexity.

Also there's no need for interoperability between different applications' scene graphs, so there's no need for a bureaucratic standards process and all the technical compromises that result from it. Standardisation is worthwhile for a static image format, so it's good that SVG achieved that, but the problem is when SVG tries to go way beyond that.)

Script inside SVG?

Posted Apr 17, 2025 20:20 UTC (Thu) by sfeam (subscriber, #2841) [Link]

"You don't need SVG for that though, you can use HTML <canvas> + JS instead"

Well yes. but so far as I know the HTML/canvas representation isn't useful for anything other than being viewed in a web browser. The svg representation is still a reasonably portable figure even when detached from its interactive js parts, and can easily be edited or modified by other tools. FWIW I have used the svg-based tool Inkscape for many years now for creating technical figures. Being able to start from, edit, or include, svg figures from gnuplot is a big plus.

Script inside SVG?

Posted Apr 19, 2025 2:15 UTC (Sat) by notriddle (subscriber, #130608) [Link]

As an example, the flamegraph reference implementation generates SVG files with embedded JS. You can see the chart even in non-interactive renderers like librsvg, but in a browser you can click a column to zoom in on it.

Script inside SVG?

Posted Apr 17, 2025 7:06 UTC (Thu) by joib (subscriber, #8541) [Link]

Well, there is precedent for this kind of (mis?)feature, e.g. Postscript. Then the world switched over to PDF, where one of the advantages was that PDF isn't a full Turing complete language, and thus less scope for issues (exploits, or DOS'ing your printer with malformed Postscript, etc.). But of course, modern PDF also has support for embedded Javascript, so plus ça change..

Script inside SVG?

Posted Apr 17, 2025 12:46 UTC (Thu) by callegar (guest, #16148) [Link]

Isn't this needed in applications like e.g., sozi (https://sozi.baierouge.fr/pages/10-about.html) for e.g., interactive presentations?

Executable content

Posted Apr 17, 2025 6:02 UTC (Thu) by oldtomas (guest, #72579) [Link] (4 responses)

Whoever thought that it is a good idea to allow arbitrary code execution to view documents deserves to... get their hacker creds revoked.

Seriously: We are in the n-th layer (after Java applets, Active-X; before that Word and Excel macros). Do people never learn?

Of course, these days, the ad industry (Google, FB and all those others by any name _are_ ad industry, after all) has discovered that it eases strip-mining their "users", so it will be very difficult to counter that push.

What makes me especially sad is that free software hackers just ape that dystopia without apparent reason: a help viewer with executable content? Seriously?

Gah. Where did we take that wrong turn?

Executable content

Posted Apr 17, 2025 8:43 UTC (Thu) by farnz (subscriber, #17727) [Link] (3 responses)

This has been a cycle since the invention of PostScript (which is a code format, not a description language).

And part of the reason that free software has the "executable content problem" is that it's reusing other free software - instead of writing a help viewer from scratch, they've written something that reuses WebKit to handle the conversion of a document format (HTML) into a display output. That's the point of free software - reuse of other people's code for your purposes, not necessarily the ones they want you to make of it.

Executable content

Posted Apr 18, 2025 7:04 UTC (Fri) by oldtomas (guest, #72579) [Link] (2 responses)

Reuse groff, then.

No, seriously. There was a lot of choice. That decision was wrong (at that time, Gnome was all gung-ho on Web "technology", horribly complexifying its whole "stack" (as they say today).

The outcome is... Google has won. Only Big Corps have the reams of money needed to tame those monsters. Software is again becoming unfree, for other reasons.

Executable content

Posted Apr 18, 2025 15:56 UTC (Fri) by farnz (subscriber, #17727) [Link] (1 responses)

You'd have the same problem starting with groff as with HTML; both HTML and groff on their own limit what you can express to what the viewer application is willing to let you express (since they're both markup languages for textual content). But there's constant demand for more expressive help documents - for example, HTML's native support for complex mathematical equations and graphs is poor - and it's simpler to solve that by executing more code (as PostScript does) that takes in a human-friendly description of what you want (MathML, for example) and outputs HTML to the rendering engine that displays what you want.

And that's the problem - the temptation, when faced with large numbers of niche problems each needing their own markup changes and a rendering engine that handles that niche well, is to provide a way for those problems to be solved by supplying code that knows about the niche, rather than by bloating the help engine with an understanding of every single niche that you might want to provide help for.

Executable content

Posted Apr 21, 2025 7:23 UTC (Mon) by oldtomas (guest, #72579) [Link]

Books don't have this problem.

Of course, the ad industry is the main driver of this "temptation". It would make sense to just resist it.

You say: "... rather than by bloating the help engine with an understanding of every single niche...".

This is a fine irony, given that e.g. on my box, firefox leads the memory hog contest. Far behind is mariadbd, trailing by a factor of two; behind that, there's a smattering of "Isolated Web Content", "Web Extensions", "Privileged Content", "Web Content" and so on (roughly 10 processes) which taken together (my guess: 20..30M RSS) dwarf *everything else* running on my box.

I have three (!) tabs open, and the firefox profile I'm using has had its javascript functionality neutered.

Bloat? Nah.

Failure of sandboxing

Posted Apr 17, 2025 14:03 UTC (Thu) by MrWim (subscriber, #47432) [Link] (10 responses)

Unlike other posters, to me it seems perfectly reasonable that a help viewer should be able to execute JavaScript. I could imagine a variety of ways that this could be useful to users.

I also think it’s unreasonable to expect that Yelp would be secure. There’s tons of small programs like Yelp that make up a usable desktop. We can’t expect every one of them to not make any mistakes.

I think the failure here is that the operating system grants these programs the capability to e.g. access arbitrary files, and contact arbitrary hosts on the Internet over arbitrary protocols.

Failure of sandboxing

Posted Apr 17, 2025 14:13 UTC (Thu) by MrWim (subscriber, #47432) [Link] (9 responses)

I guess the way I think about it is not “JavaScript in Yelp can read ~/.ssh/id_rsa and upload it to baddies.ru”, but more like “Yelp asked the OS to read ~/.ssh/id_rsa, and it gladly handed the data over. It then asked the os to send some data to baddies.ru and it did so without question”.

Failure of sandboxing

Posted Apr 17, 2025 19:28 UTC (Thu) by epa (subscriber, #39769) [Link] (8 responses)

You are right, but if there's one lesson of security failures, it's that you need to fix all the lines of defence. The web browser shouldn't launch an external program such as Yelp without user intervention. Yelp shouldn't let the help file pass through a <script> element verbatim to the final HTML. Even if <script> or <svg:script> does appear, the JavaScript engine should be fussier about whether to run it. Even if it does run, perhaps the JavaScript engine shouldn't grant network access or local filesystem access by default. And even if all those steps fail, the yelp binary itself should run in some kind of sandbox that forbids it access to ~/.ssh or the network without explicit user approval. (That last step applies to many small programs, as you noted.)

Failure of sandboxing

Posted Apr 17, 2025 21:55 UTC (Thu) by khim (subscriber, #9252) [Link] (4 responses)

The big problem with all that reasoning is that it's very hard to “tighten the screws” and not make users run somewhere.

If your OS was designed from the very beginning not to allow integration between programs except in a severely restricted form, then it's very hard to add any semblance of sane security restrictions without users immediately declaring your worshiper of Satan for breaking your workflow.

That's why I'm a bit sad that it takes so much for Google to finally replace ChromeOS with Android (like they should have done years ago).

Then we would finally have kinda-sorta-OSS desktop OS with lots of software.

Of course a lot of people would complain when that would happen, anyway… It's not possible to win there, ultimately, only lose… lose less or lose more, but you always lose.

Failure of sandboxing

Posted Apr 18, 2025 6:28 UTC (Fri) by epa (subscriber, #39769) [Link] (3 responses)

Yes. For the particular case of a help browser, what it does is so limited that sandboxing should be possible. For other applications retrofitting a sandbox can create a maze of authentication prompts that users quickly turn off (or train themselves to ignore). Or functionality may just be lost. We see some of the same effects with apps packaged as snaps by Ubuntu, which don’t always integrate fully with the rest of the system, I believe.

(I’d like to see a file open dialogue box that grants permission to a sandboxed app to open that file but no other; similarly for saving.)

Failure of sandboxing

Posted Apr 18, 2025 10:11 UTC (Fri) by ebassi (subscriber, #54855) [Link]

> (I’d like to see a file open dialogue box that grants permission to a sandboxed app to open that file but no other; similarly for saving.)

That's literally the file chooser portal: https://flatpak.github.io/xdg-desktop-portal/docs/doc-org...

Which is what GTK, for instance, uses out of the box with its GtkFileDialog API: https://docs.gtk.org/gtk4/class.FileDialog.html

The file selection dialog runs on the host, and exposes only the user selected file(s) into the sandbox.

Failure of sandboxing

Posted Apr 18, 2025 16:45 UTC (Fri) by vonbrand (guest, #4458) [Link] (1 responses)

And all users are fine with checking what "123_PGR_xvg.js" does. Heck, I would understand around half of the code, and would not appreciate to have to interrupt my work (already interrupted looking for help, or whatever) to launch an audit on some recondite snippet of code of no interest to me.

Failure of sandboxing

Posted Apr 22, 2025 9:22 UTC (Tue) by epa (subscriber, #39769) [Link]

I imagined that reading a file that's installed on the system (and readable to all local users) wouldn't require a prompt, but reading a file which is under the user's home directory would prompt, and doubly so if it's not world-readable.

Failure of sandboxing

Posted Apr 18, 2025 16:40 UTC (Fri) by vonbrand (guest, #4458) [Link] (2 responses)

Excluding "without user intervention" leads to "click yes, click yes" conditioning, followed by occasional "OOPS"...

Failure of sandboxing

Posted Apr 18, 2025 18:04 UTC (Fri) by MrWim (subscriber, #47432) [Link]

Indeed, security dialogs are pointless - the user won’t know how to answer the dialog anyway, and they will almost always click allow as they’re trying to get something done.

Perhaps some lessons could be learned from how systemd applies security restrictions. There’s a simple list of restrictions in an easily edited .ini file that is shipped with the service. If the upstream doesn’t provide one, or provides an overly liberal policy then the distro can override it. Changing the policy or adding a new one doesn’t require rebuilding or modifying the service. Most services only need access to a very narrow slice of the system, so it can be quick and easy to remove most access.

Such a system doesn’t help against malicious installed apps, and it’s not as powerful as e.g. a fully containerised or capability based system, but it’s easy to apply broadly.

Failure of sandboxing

Posted Apr 18, 2025 19:38 UTC (Fri) by epa (subscriber, #39769) [Link]

The "user intervention" I mentioned in my earlier comment was when downloading a file from a website to launch it in an external program. It's standard in most web browsers, and I believe the reporter of this CVE has filed a bug against Epiphany to do the same. It doesn't condition the user to click "yes" automatically, in my view, because downloading a file and opening it in an external program is quite a rare operation compared to just clicking through ordinary links.

For the more general point, you are right, and I don't suggest a blizzard of prompts for file access by a sandboxed program. Rather, the user intervention comes at the point the user is involved anyway: when using the file open dialogue box. If the program does need to access "private" files without explicit opening by the user, I guess a single prompt for elevated permissions would work (as happens in Windows).