Bug#352575: display file:/// deletes its file
On Mon, Feb 13, 2006 at 03:59:49PM +0100, Daniel Kobras wrote: > On Mon, Feb 13, 2006 at 01:59:55PM +0100, Nicolas George wrote: > > Le quintidi 25 pluviôse, an CCXIV, Daniel Kobras a écrit : > > > Are you aware of any applications that pass an URI to a mime handler > > > rather than just the local path and filename? Furthermore, the mailcap > > > entries in testing and unstable now prefix the filename with a format > > > string based on the mime type, which makes it impossible to trigger this > > > bug via the mime handler route. > > > > I remembered in Gnome Control Center applications settings a checkbox "Can > > open _URIs", but now that I look in the source, I see the code that takes > > this checkbox into account is commented out. So I guess I can not give any > > example, which is somehow a relief. > > Understood, thanks! In any case, here's the patch that fixes this > problem. Ryuichi, I intend to upload an NMU to address this grave bug as > soon as possible. Full diff attached. Oh, and for the record: The version in stable only groks http:// and ftp://, and therefore is not affected by this problem. Same for graphicsmagick in unstable. Regards, Daniel.
Processed: Re: Bug#352575: display file:/// deletes its file
Processing commands for [EMAIL PROTECTED]: > tag 352575 + patch Bug#352575: display file:/// deletes its file Tags were: security Tags added: patch > thanks Stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#352575: display file:/// deletes its file
tag 352575 + patch
thanks
On Mon, Feb 13, 2006 at 01:59:55PM +0100, Nicolas George wrote:
> Le quintidi 25 pluviôse, an CCXIV, Daniel Kobras a écrit :
> > Are you aware of any applications that pass an URI to a mime handler
> > rather than just the local path and filename? Furthermore, the mailcap
> > entries in testing and unstable now prefix the filename with a format
> > string based on the mime type, which makes it impossible to trigger this
> > bug via the mime handler route.
>
> I remembered in Gnome Control Center applications settings a checkbox "Can
> open _URIs", but now that I look in the source, I see the code that takes
> this checkbox into account is commented out. So I guess I can not give any
> example, which is somehow a relief.
Understood, thanks! In any case, here's the patch that fixes this
problem. Ryuichi, I intend to upload an NMU to address this grave bug as
soon as possible. Full diff attached.
Regards,
Daniel.
diff -u imagemagick-6.2.4.5/debian/changelog
imagemagick-6.2.4.5/debian/changelog
--- imagemagick-6.2.4.5/debian/changelog
+++ imagemagick-6.2.4.5/debian/changelog
@@ -1,3 +1,11 @@
+imagemagick (6:6.2.4.5-0.7) unstable; urgency=high
+
+ * Non-maintainer upload.
+ * coders/url.c: Do not treat local file:// URIs as temporary files that
+are removed after reading. Closes: #352575
+
+ -- Daniel Kobras <[EMAIL PROTECTED]> Mon, 13 Feb 2006 14:49:49 +0100
+
imagemagick (6:6.2.4.5-0.6) unstable; urgency=high
* Non-maintainer upload.
only in patch2:
unchanged:
--- imagemagick-6.2.4.5.orig/coders/url.c
+++ imagemagick-6.2.4.5/coders/url.c
@@ -157,8 +157,12 @@
LocaleLower(filename);
(void) ConcatenateMagickString(filename,image_info->filename,MaxTextExtent);
if (LocaleCompare(read_info->magick,"file") == 0)
-(void) CopyMagickString(read_info->filename,image_info->filename+2,
- MaxTextExtent);
+{
+ (void) RelinquishUniqueFileResource(read_info->filename);
+ unique_file = -1;
+ (void) CopyMagickString(read_info->filename,image_info->filename+2,
+MaxTextExtent);
+}
#if defined(HasXML) && defined(LIBXML_FTP_ENABLED)
if (LocaleCompare(read_info->magick,"ftp") == 0)
{
@@ -205,7 +209,8 @@
(void) fclose(file);
*read_info->magick='\0';
image=ReadImage(read_info,exception);
- (void) RelinquishUniqueFileResource(read_info->filename);
+ if (unique_file != -1)
+(void) RelinquishUniqueFileResource(read_info->filename);
read_info=DestroyImageInfo(read_info);
if (image == (Image *) NULL)
(void) ThrowMagickException(exception,GetMagickModule(),CoderError,
Bug#352575: display file:/// deletes its file
Le quintidi 25 pluviôse, an CCXIV, Daniel Kobras a écrit : > Are you aware of any applications that pass an URI to a mime handler > rather than just the local path and filename? Furthermore, the mailcap > entries in testing and unstable now prefix the filename with a format > string based on the mime type, which makes it impossible to trigger this > bug via the mime handler route. I remembered in Gnome Control Center applications settings a checkbox "Can open _URIs", but now that I look in the source, I see the code that takes this checkbox into account is commented out. So I guess I can not give any example, which is somehow a relief. Regards, -- Nicolas George signature.asc Description: Digital signature
Bug#352575: display file:/// deletes its file
On Sun, Feb 12, 2006 at 08:14:40PM +0100, Nicolas George wrote: > If display is called on a file:/// URL, it deletes the images after > displaying it. Steps to reprodude: > > cp /some/image.jpg /tmp/test.jpg > display file:///tmp/test.jpg > Quit display: /tmp/test.jpg is gone. Uh, that's a grave bug indeed. Also happens with other tools from the ImageMagick suite like identify, by the way. > Since display may be MIME handler for images, and configured to take URLs > and not paths, this may be a security risk in some cases. I'm not convinced about the security implications of this bug, though. Are you aware of any applications that pass an URI to a mime handler rather than just the local path and filename? Furthermore, the mailcap entries in testing and unstable now prefix the filename with a format string based on the mime type, which makes it impossible to trigger this bug via the mime handler route. Regards, Daniel. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#352575: display file:/// deletes its file
Package: imagemagick Version: 6:6.2.4.5-0.6 Severity: grave Justification: user security hole Tags: security If display is called on a file:/// URL, it deletes the images after displaying it. Steps to reprodude: cp /some/image.jpg /tmp/test.jpg display file:///tmp/test.jpg Quit display: /tmp/test.jpg is gone. Since display may be MIME handler for images, and configured to take URLs and not paths, this may be a security risk in some cases. -- (Probably useless) System Information: Debian Release: testing/unstable APT prefers testing APT policy: (500, 'testing'), (500, 'stable'), (50, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/dash Kernel: Linux 2.6.14.1 Locale: LANG=C, LC_CTYPE=fr_FR (charmap=ISO-8859-1) Versions of packages imagemagick depends on: ii libbz2-1.0 1.0.3-2 high-quality block-sorting file co ii libc6 2.3.5-13 GNU C Library: Shared libraries an ii libfreetype6 2.1.7-2.4 FreeType 2 font engine, shared lib ii libice66.9.0.dfsg.1-4Inter-Client Exchange library ii libjasper-1.701-1 1.701.0-2 The JasPer JPEG-2000 runtime libra ii libjpeg62 6b-11 The Independent JPEG Group's JPEG ii liblcms1 1.13-1Color management library ii libmagick9 6:6.2.4.5-0.6 Image manipulation library ii libpng12-0 1.2.8rel-5PNG library - runtime ii libsm6 6.9.0.dfsg.1-4X Window System Session Management ii libtiff4 3.7.4-1 Tag Image File Format (TIFF) libra ii libx11-6 6.9.0.dfsg.1-4X Window System protocol client li ii libxext6 6.9.0.dfsg.1-4X Window System miscellaneous exte ii libxml22.6.23.dfsg.1-0.1 GNOME XML library ii zlib1g 1:1.2.3-9 compression library - runtime signature.asc Description: Digital signature
