Closed Bug 301193 Opened 19 years ago Closed 16 years ago

Modified file extension handling crashes trunk builds

Categories

(Core Graveyard :: File Handling, defect)

Product:
Core Graveyard
Component:
File Handling
Version:
1.8 Branch
Platform:
x86
Windows XP
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED WORKSFORME

People

(Reporter: mikx, Assigned: Biesinger)

Details

Attachments

(1 file)

.pif demo file
2.79 KB, application/octet-stream
Details 
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b4) Gecko/20050717 Firefox/1.0+
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b4) Gecko/20050717 Firefox/1.0+

The recent changes to get around security bugs exploiting image drag and drop,
.lnk/.pif file abuse and file download dialogs seem to have influenced the
behavior of trunk builds.


Reproducible: Always




There are different behaviors when comparing trunk and Firefox 1.0.5, and i am
not sure if all of them are on purpose and if those changes might have
introduced some regressions and/or a new security bug.

Difference 1: In Firefox 1.0.5 you can modify the extension of a file you
download via ALT-Click on a link. On trunk you can't. This could be seen as a
regression bug. For example you can not properly download a dynamicly generated
PDF file using this shortcut (makepdf.php generating a pdf file and sending
headers to change filename to foo.pfd does not work. Gets saved as makepdf.php).

Please see bug #301186, maybe this is related. Use the following code to repro:

<?php
$fp = fopen("foo.pdf", "rb");
header("Content-Type: application/pdf");
header("Content-Disposition: inline; filename=foo.pdf");
fpassthru($fp);
fclose($fp);
?>

Difference 2: When you drag a dynamicly generated image (which isn't a valid
image but an .pif file) to your desktop, in Firefox 1.0.5 you just create a
webpage shortcut. The trunk build crashes. Use the following code to repro:

save as foo.php
<?php
$fp = fopen("foo.pif", "rb"); 
header("Content-Type: image/gif");
header("Content-Disposition: inline; filename=foo.pif");
fpassthru($fp);
fclose($fp);
?>

save as foo.html
<html><img src="foo.php"> drag this to your desktop</html>

This bug seems to be related to the content type image/gif only. Maybe it is
some kind of bug in the image parser or it happens when the temporary file for
the drag process get's created. Not sure if you could exploit this (buffer
overflow?). Assuming the browser wouldn't crash, could there be a situation when
windows executes the pif file when copying the file from temp to the final
destination?
Attached file .pif demo file — 

  

  



    
    

    
  
If you are not the right person to assign this to, please help us find someone that is.

  

  


Assignee: nobody → cbiesinger
Component: General → File Handling
Product: Firefox → Core
Version: unspecified → 1.8 Branch

    
    

    
  
I can't reproduce this bug in either trunk or 1.8.0 nightly builds...

  

  



    
    

    
  
this bug is another one to get up on a php test server.

  

  



    
    

    
  
The first issue has been fixed:
Fixed on trunk
  * tested on Windows XP SP2 and Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b3pre) Gecko/2008012304 Minefield/3.0b3pre
  * alt-clicking link presents "Save link as" dialog, which displays the php page by default, but the user can change the file name and extension which is preserved upon saving.

Fixed on branch
  * tested on Windows XP SP2 and Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.11) Gecko/20071127 Firefox/2.0.0.11
  * alt-clicking link presents "Save link as" dialog, which displays the php page by default, but the user can change the file name and extension which is preserved upon saving.

The second issue appears to still be valid:
Still open on trunk
  * I set up the PoC as indicated, using the attached .pif file as the contents of the dynamically-generated image.  Dragging-and-dropping the image onto the desktop only creates a shortcut to the location of the PHP file that created it.
  * This is as opposed to the behavior seen when dragging-and-dropping a dynamically-created .gif or .png onto the desktop, which saves the image content to the desktop, but with the full filename of the .php file that created the image.  We do not appear to be respecting the filename specified in the Content-Disposition header.  SHOULD THIS BE BUGGED SEPARATELY?
  * tested on Windows XP SP2 and Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b3pre) Gecko/2008012304 Minefield/3.0b3pre

Still open on branch
  * somewhat similar behavior to trunk
  * Dragging-and-dropping the dynamically-created .pif image onto the desktop only creates a shortcut to the location of the PHP file that generated it.
  * dragging/dropping a dynamically-generated .gif or .png file saves the image content to the desktop and preserves the file extension, but not the filename specified in the Content-Disposition header.  Instead the file is created with the name of the PHP script that generated the image.  Again, SHOULD THIS BE BUGGED SEPARATELY?
  * tested on Windows XP SP2 and Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.11) Gecko/20071127 Firefox/2.0.0.11


  

  


Status: UNCONFIRMED → NEW
Ever confirmed: true

    
    

    
  
Looks like scenario 1 has been fixed. Scenario 2 was related to a crash which no longer repros either.

  

  


Status: NEW → RESOLVED
Closed: 16 years ago
Resolution: --- → FIXED
Group: core-security

    
    

    
  
No bug or patch referenced as the fix.

  

  


Resolution: FIXED → WORKSFORME
Product: Core → Core Graveyard

          You need to log in
          before you can comment on or make changes to this bug.
        






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: