0

I see many software that check only for..between path separators. For a long time I thought they were no possibility to exploit invalid bytes (for example attempt to create.‌.will lead to.?.on osx).

But I saw cve‑2003‑0282 yesterday. So what are the invalid characters that can trigger that bug on vulnerable versions.

I tried to search more about this, but it sees all the relevant links on the cve report are dead.

user2284570
  • 1,472
  • 1
  • 14
  • 35

1 Answers1

0

From the patch it can be seen that it is skipping any control and some more characters ([\x00-\x1f\x7f\xff]) when constructing the target file name:

+        * SECURITY: Skip past control characters if the user
+        * didn't OK use of absolute pathnames. lhh - this is
+        * a very quick, ugly, inefficient fix; it traverses
+        * the WHOLE path, eating up these as it comes to it.
+        */
+       dp = cp;
+       do {
+           workch = (uch)(*dp);
                 ...
+            } else if (workch == '.' && !snarf_ddot) {
+               snarf_ddot = TRUE;
+           } else if (isprint(workch) ||
+                      ((workch > 127) && (workch <= 254))) {
+               /*
+                * Since we found a printable, non-ctrl char,
+                * we can stop looking for '../', the amount
+                * in ../!
+                */
+               break;
+           }
+
+           dp++;
+        } while (*dp != 0);
Steffen Ullrich
  • 201,479
  • 30
  • 402
  • 465
  • Good, I was unable to find the patch. However, it stills doesn’t resolve the problem : in other archivers the file containing those character would simply be created. – user2284570 May 06 '16 at 17:10
  • @user2284570: which problem you describe? This patch removes special characters when extracting the files from the archive so that it does not matter if some other archiving program created a malicious archive. – Steffen Ullrich May 06 '16 at 17:44
  • : normally if create a file ᴀꜱᴄɪɪ control characters with it’s name, the filename will contains them. I can’t see how see how they could have been stripped when attempting to create... – user2284570 May 06 '16 at 21:24
  • @user2284570: sorry, but I'm unable to understand your problem. It might help if you explain it in more depth and also add more context. – Steffen Ullrich May 07 '16 at 05:56
  • repeating it differently : normally if your create a file ᴀꜱᴄɪɪ control characters with it’s name, the filename will contains them. So what should happen is a new directory is created instead of..being recognized and leading to path traversal. – user2284570 May 07 '16 at 12:59
  • @user2284570: still not clear what your problem is. Maybe we have a different understanding what the code is doing: it is simply ignoring control characters when looking for directory traversal pattern, i.e. .. and .\x03. will be treated the same and traversal attempt is detected. – Steffen Ullrich May 07 '16 at 13:56
  • Yes, what I do not understand is why such bytes are ignored (or rather than why they were ignored on vulnerable versions). – user2284570 May 07 '16 at 22:42
  • @user2284570: I still don't understand your problem. Please try to describe it in more than a short phrase. Your question makes probably sense in your current mindset but I don't know this mindset so you need to go back and explain the context of your question deep enough so that I and maybe others can understand it. – Steffen Ullrich May 08 '16 at 05:29