-
Notifications
You must be signed in to change notification settings - Fork 60
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
Adding malicious symbolic links to an EPUB publication #2322
Comments
I'd expect epubcheck would report the link as invalid without needing to detect that it's a symlink. Now that we're defining a unique origin for each publication, a relative symlink won't escape the structure of the publication, so there won't be a resource at the location. And if we disallow file URLs, absolute symbolic links will be flagged. The same would be true on the reading system side, so long as it follows the new requirements. |
I may be wrong, but symlinks would not be impacted by anything we say about URLs, would they? Symlinks are basically OS-dependent special files.
I'll look if EPUBCheck can easily detect that. |
I agree, @rdeltour. Epubcheck should, if it is able to, detect that they are a very special file on the file system in the zip content; they are os dependent. |
Ya, but you can't put a symlink in an epub publication, can you? How would that work if the properties aren't set to make it a symbolic link? I thought this was about referencing a symlink to access a location on the local filesystem, like a path starting with I don't know how we stop it from a script, though. |
ZIPs can be created to store a symlink (eg. with the |
Ah, right, my mistake. I was thinking we blocked that in OCF, but nope. |
The issue was discussed in a meeting on 2022-06-09 List of resolutions:
View the transcript3. Adding malicious symbolic links to an EPUB application.See github issue epub-specs#2322. Dave Cramer: symbolic link outside the epub pointing to local fs, should we discuss this in threat model and/or explicitly disallow. Brady Duga: there is a parameter to include symlink in zip. Dave Cramer: yes, -y. Wendy Reid: i think so. Brady Duga: this one is more obscure, easy for people not to think of this. So maybe just a notice to watch out for this, and similar threats of files referencing other files. Matt Garrish: could it be a MUST though? "RS must not preserve symbolic link when unpacking" something like that. Brady Duga: it depends on the fs, the OS... not sure how I would tell people not to do this, and I don't want to limit this to the way you would do it using zip. Dave Cramer: and if you have a really bad RS that allows scripting, and the script asks the local fs to do stuff. Ben Schroeter: is epubcheck looking into this issue?. Matt Garrish: romain is looking into whether epubcheck could detect such symlinks.
|
So, I tried to make an EPUB with a symbolic link. Made a symbolic link to one of my spine items in MacOS. Zipped with the -y flag. EPUBCheck was not happy:
Reading systems were also not happy. Thorium opened the book but had an error message for that spine item: I expect what I found is very specific to a particular operating system. |
... but also shows that such a restriction can be implemented and tested. Ie, it makes sense to add explicitly to the spec. Thanks! And keep your code, you got yourself a test :-) |
There are actually several similar notions:
I am familiar with (1) and (2), not really with (3) and (4). But they all strike me as somewhat similar. Before getting into spec text, there are some questions to answer
|
Looking at #2322 (comment) we may get this in the wrong order. What about:
We then avoid the necessity to list the various aliases like shortcut files or symbolic links, but we also avoid other possibly thorny issues like files representing sockets, special files like print device, and other hairy thing that the operating system may come up with. I do not think this would unduly restrict any deployed publication out there, and would greatly reduce the security risk. Is that a realistic restriction from the point of view of epubcheck or a reading system? |
About EPUBCheck:
"ordinary files or directories" sound a bit vague. An alias file is really an ordinary file, just having some special behavior on a specific OS. Also, there are other shortcut-like files out there. For instance |
Yes, I was fighting with this myself. I took the terminology in the unix world; the closest to a more formal definition that I found was in https://www.geeksforgeeks.org/unix-file-system/. There may be some ways of referencing this better but I did not find it; is there an authoritative reference to Linux and/or Unix that one could use? (But your example for the MacOS alias file is discomforting...) I am a bit worried about starting by enumerating the type of file we do not want to allow. That is also a fragile approach... (what happens if someone has the bad idea to put a file of the sort |
Can't we exclude them based on their all having the same function:
|
The approach in #2322 (comment) might work, but I am not sure how we would clearly specify "affecting pathname resolution". And it would still allow for some other nasty files like Just for the records, I was also looking at the references to make #2322 (comment) cleaner, and I could locate at least a stable UNIX reference, namely The Open Group Base Specifications Issue 7, 2018 edition which has terminology definitions for some file related concepts. One alternative is to refer to those and say that we accept only regular files and directories an nothing else.
I am not arguing this is the way we should go, just putting out there for discussion... (and we should be sure that MacOS alias files are also excluded...) |
I think this is going to be hard to spec given that it depends on implementation details. For instance, referencing a symbolic link may or may not change the pathname. On *nix platforms you could have a hard link - do we want to forbid that? Probably not. My feeling was that this is a novel attack and one implementors may not be aware of so it seems worth mentioning in the security section for Reading Systems, but not with a hard requirement. Something more like "Attackers may try to gain access to non-publication resources using file indirection techniques (for example, symbolic links or file aliases). It is the Reading Systems responsibility to ensure that malicious content cannot gain access to non-publication resources using this attack." Or maybe just the first sentence of that. |
If we can't clearly specify symbolic links, then how do we specify the superset of files that have "no further structure imposed by the system"? From what I've read, storing symbolic links of any type is non-standard and not univerally supported. There are implementations that use the external file attribute in the central directory record to store the information, but I'm not even sure that's universal given that mac aliases work on an identifiable byte sequence in the file. In other words, I'm fine with only noting this in the reading system specification, since attempts to ban the practice on the authoring side are probably going to be incomplete, and won't account for reading systems loading unpacked epubs. Maybe we just informatively warn authors that they shouldn't include these kinds of files or expect them to function as expected. Short of hackery in the package document to hide them as foreign resources with fallbacks, isn't the only way to legitimately exploit symbolic links to include the files without any reference to them and then use a script to read whatever data is loaded? (i.e., hide them as data files.) It's not really a practice you can innocently stumble on. |
Just trying to find a way forward (also before our call tomorrow to have something clear to be voted upon)
I am wondering whether we can do something slightly stronger in place of (3) using SHOULD NOT instead of MUST NOT. The only reason is that, per #2322 (comment), epubcheck could filter out some cases, and that is probably a useful thing to legitimately warn the user about... |
The issue was discussed in a meeting on 2022-06-17 List of resolutions:
View the transcript1. Malicious Symbolic Links in EPUB.See github issue epub-specs#2322. Dave Cramer: this was raised as possible security issue as a way to create links to the local fs. Because these things are OS dependent, we have been working on how to define this requirement, and how stringent to be. Also investigating how epubcheck can help.
Brady Duga: the SHOULD NOT is a little weird because the purpose of SHOULD is that 'we don't think you should do this, but there are exceptional cases where it might make sense'. Matt Garrish: why not make it make it a MUST NOT and accept that epubcheck can't catch everything?. Brady Duga: problem with a MUST is that we are trying to define behaviour over an undefined concept, so it's hard to put normative statements around that. Ivan Herman: agreed. I've tried to find language to fit this, but I couldn't.. Brady Duga: this isn't a real problem, there aren't a lot of epubs with symlinks in it. If you do put symlink it, your epub will probably break on most RS.. Dave Cramer: and we're already catching some of this. I tested this in an epub, and epubcheck threw an error. Matt Garrish: you could set the symlink as a data file to prevent it from being checked, but if someone is up to no good there isn't a guaranteed way to find it. Dave Cramer: i could see it being done accidentally, like if you had an alias on your desktop and accidentally put it in your epub.
|
As discussed in the meeting with @GJFR (see EPUB meeting) a malicious EPUB publication may include a symbolic link in its content pointing 'outside' the container to the local file system. This threat should be documented in the §15.2 Thread model of the reading system.
We may also consider explicitly disallowing such files in the content document, but only if epubcheck is able to find those in the content. @rdeltour @mattgarrish ?
The text was updated successfully, but these errors were encountered: