<?xml version="1.0" encoding="UTF-8"?> 
<?xml-stylesheet href="https://dev.horde.org/themes/horde//default/feed-rss.xsl" type="text/xsl"?> 
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"> 
 <channel> 
  <title>Driver &#039;file&#039; fails to open files with &#039;..&#039; anywhere in name</title> 
  <pubDate>Fri, 10 Apr 2026 02:21:32 +0000</pubDate> 
  <link>https://bugs.horde.org/ticket/7646</link> 
  <atom:link rel="self" type="application/rss+xml" title="Driver &#039;file&#039; fails to open files with &#039;..&#039; anywhere in name" href="https://bugs.horde.org/ticket/7646/rss" /> 
  <description>Driver &#039;file&#039; fails to open files with &#039;..&#039; anywhere in name</description> 
 
   
   
  <item> 
   <title>This may already be fixed upstream in latest head, and if so</title> 
   <description>This may already be fixed upstream in latest head, and if so, please forgive. I am using 1.0.3 because it&#039;s what&#039;s in Ubuntu 8.04 LTS&#039;s repository as of the latest apt-get update.



When using the &#039;file&#039; VFS driver on a Linux host using Horde 3.1.7, IMP H3 4.1.4 and Gollem H3 1.0.3, users are unable to open (or attach to IMP outgoing messages), any files that contain &#039;..&#039; anywhere in the file name. Test case:



Create a file in a VFS share with the filename &#039;test.pdf&#039;. Opens correctly.

Rename the file to &#039;test..pdf&#039;. The file will silently fail to attach to IMP messages, and will fail to view with the following error:



-------------------------------------------------



Warning: file_get_contents(/vfsdir/horde//filepdf) [function.file-get-contents]: failed to open stream: No such file or directory in /usr/share/horde3/lib/VFS/file.php on line 82



Warning: Cannot modify header information - headers already sent by (output started at /usr/share/horde3/lib/VFS/file.php:82) in /usr/share/horde3/lib/Horde/Browser.php on line 978



Warning: Cannot modify header information - headers already sent by (output started at /usr/share/horde3/lib/VFS/file.php:82) in /usr/share/horde3/lib/Horde/Browser.php on line 984



Warning: Cannot modify header information - headers already sent by (output started at /usr/share/horde3/lib/VFS/file.php:82) in /usr/share/horde3/lib/Horde/Browser.php on line 1003



-----------------------------------------------



Solution: I opened up /usr/share/horde3/lib/VFS/file.php and found the error inside of _getNativePath where &#039;..&#039; is replaced with &#039;&#039;. The reason for this is obvious (security), but the method failed to take into account situations like this where the user just accidentally put two ..&#039;s before an extension. I replaced the str_replace call with an ereg_replace call to only do this at the beginning of the filename. Works like a charm. I tried naming files things like &#039;../sneakyfile.pdf&#039; and such, and gollem wasn&#039;t freaked out by any tests I could do.



Patch is attached to bug report in unified diff format.</description> 
   <pubDate>Wed, 05 Nov 2008 22:23:58 +0000</pubDate> 
   <link>https://bugs.horde.org/ticket/7646#t50298</link> 
  </item> 
   
  <item> 
   <title>What about paths like file.pdf/../../../etc/passwd ?



Much</title> 
   <description>What about paths like file.pdf/../../../etc/passwd ?



Much less importantly, ereg_* is deprecated and against Horde CS; please use the pcre functions instead (although this particular case doesn&#039;t even need a regex).</description> 
   <pubDate>Thu, 06 Nov 2008 01:36:42 +0000</pubDate> 
   <link>https://bugs.horde.org/ticket/7646#t50308</link> 
  </item> 
   
  <item> 
   <title>&gt; What about paths like file.pdf/../../../etc/passwd ?



I </title> 
   <description>&gt; What about paths like file.pdf/../../../etc/passwd ?



I tried that, and it&#039;s stripped out. Any filename that has / in it (on my unix box, at least) will only use the portion after the last / , as if you had run &#039;basename&#039; against it. So in this case the file is simply renamed &#039;passwd&#039; in the current directory.



&gt; Much less importantly, ereg_* is deprecated and against Horde CS; 

&gt; please use the pcre functions instead (although this particular case 

&gt; doesn&#039;t even need a regex).



I just used a regex &#039;cause it was the only way I knew for sure to only check the beginning of the string. I&#039;ll submit another patch later today that uses pcre instead.</description> 
   <pubDate>Thu, 06 Nov 2008 13:38:33 +0000</pubDate> 
   <link>https://bugs.horde.org/ticket/7646#t50398</link> 
  </item> 
   
  <item> 
   <title>&gt; I just used a regex &#039;cause it was the only way I knew for </title> 
   <description>&gt; I just used a regex &#039;cause it was the only way I knew for sure to 

&gt; only check the beginning of the string. I&#039;ll submit another patch 

&gt; later today that uses pcre instead.



http://php.net/substr



etc...



Thanks!</description> 
   <pubDate>Thu, 06 Nov 2008 15:16:48 +0000</pubDate> 
   <link>https://bugs.horde.org/ticket/7646#t50402</link> 
  </item> 
   
  <item> 
   <title>Are you going to provide an updated patch?</title> 
   <description>Are you going to provide an updated patch?</description> 
   <pubDate>Mon, 17 Nov 2008 15:23:06 +0000</pubDate> 
   <link>https://bugs.horde.org/ticket/7646#t50811</link> 
  </item> 
   
  <item> 
   <title>&gt; Are you going to provide an updated patch?



Yes, sorry, </title> 
   <description>&gt; Are you going to provide an updated patch?



Yes, sorry, I&#039;ve been in the thick of things recently. I&#039;m going to try to get time for another patch later today. If I don&#039;t provide a patch by 5 pm EST November 18 2008, then someone else can feel free to step in.</description> 
   <pubDate>Mon, 17 Nov 2008 18:04:49 +0000</pubDate> 
   <link>https://bugs.horde.org/ticket/7646#t50824</link> 
  </item> 
   
  <item> 
   <title>Ping again?</title> 
   <description>Ping again?</description> 
   <pubDate>Mon, 15 Dec 2008 02:54:21 +0000</pubDate> 
   <link>https://bugs.horde.org/ticket/7646#t51264</link> 
  </item> 
   
  <item> 
   <title>Noticed the same problem: gollem doesn&#039;t work correctly for </title> 
   <description>Noticed the same problem: gollem doesn&#039;t work correctly for files with multiple consecutive dots in name. Patch for this is attached. Since basename already removes directory path from the name there is no need to remove consecutive dots from the file name. The only security problem to check is the file name equal to &quot;..&quot;</description> 
   <pubDate>Mon, 07 Jun 2010 11:11:16 +0000</pubDate> 
   <link>https://bugs.horde.org/ticket/7646#t59041</link> 
  </item> 
   
  <item> 
   <title>Changes have been made in CVS for this ticket:

Bug: 7646
Su</title> 
   <description>Changes have been made in CVS for this ticket:

Bug: 7646
Submitted by: Valentin.Vidic@CARNet.hr
Allow access to files with multiple consecutive dots in the name
http://cvs.horde.org/diff.php/framework/VFS/lib/VFS/file.php?rt=horde&amp;r1=1.1.2.6&amp;r2=1.1.2.7&amp;ty=u
http://cvs.horde.org/diff.php/framework/VFS/package.xml?rt=horde&amp;r1=1.36.4.34&amp;r2=1.36.4.35&amp;ty=u</description> 
   <pubDate>Tue, 29 Jun 2010 04:51:14 +0000</pubDate> 
   <link>https://bugs.horde.org/ticket/7646#t59259</link> 
  </item> 
   
  <item> 
   <title>Changes have been made in Git for this ticket:

MFB: Bug #76</title> 
   <description>Changes have been made in Git for this ticket:

MFB: Bug #7646
Submitted by: Valentin.Vidic@CARNet.hr
Allow access to files with multiple consecutive dots in the name

Revision   Changes    Path
1.1.2.7    +4 -2      framework/VFS/lib/VFS/file.php
1.36.4.35  +2 -1      framework/VFS/package.xml

http://git.horde.org/diff.php/framework/VFS/lib/VFS/file.php?rt=horde-git&amp;r1=079bd8d84c09d7fbef27cdf291f3d94ed203b5d7&amp;r2=083dda2bd5e0b8408cc0b9c18a4a20416806214e
http://git.horde.org/diff.php/framework/VFS/package.xml?rt=horde-git&amp;r1=079bd8d84c09d7fbef27cdf291f3d94ed203b5d7&amp;r2=083dda2bd5e0b8408cc0b9c18a4a20416806214e</description> 
   <pubDate>Tue, 29 Jun 2010 04:52:48 +0000</pubDate> 
   <link>https://bugs.horde.org/ticket/7646#t59260</link> 
  </item> 
   
   
 
 </channel> 
</rss> 
