290720 - Downloading (shell) configuration files (such as .bashrc) into home directory without warning (or using a prefix) is an insecure default (unless some time in future there are no config files in home directory)

Status: RESOLVED WONTFIX

(SeaMonkey :: General, enhancement)

Description

[Andy]

User-Agent:       Mozilla/5.0 (compatible; Konqueror/3.3; Linux; en_US, ru, de) (KHTML, like Gecko)
Build Identifier: 1.7.6

It's not a vulnerability, just an insecure default, that requires certain     
(although likely) user action.     
     
1. Topic     
========     
Shells (and some other programs) use config files that reside directly in home      
directory), but browsers and many other programs don't warn against      
downloading (shell) configuration files, such as .bashrc even when downloading      
into home directory.      
      
      
2. Relevant releases/architectures      
==================================      
      
Operating Systems affected: Linux, *BSD?, Solaris?      
      
Programs affected:      
  1) Shells: bash, csh, tcsh, ...      
  2) Programs that have their config files in home directory that allow      
     to change executables called by them (e.g. for printing, converting,      
     (g)unzipping, ...), for example      
		  gv      
		  grip      
		  ...      
  3) Browsers(?): Mozilla 1.7.3, 1.7.5      
		  Opera 7.11, 7.54      
		  w3m 0.5.1      
		  Konqueror 3.2.3, 3.3.2      
  4) E-Mail clients(?): Mozilla 1.7.5      
  5) Any other program that downloads/stores files from the internet,      
     such as instant messengers, download managers,...(?)      
  6) Other?      
See (**) below for explanation of (?).      
      
      
3. Proof of concept      
===================      
  There is no way to demonstrate this insecure default nondestructively.      
  Therefore, all people whishing to see the effects of this insecure default      
  MUST BACKUP THE FOLLOWING FILES FIRST: `~/.bashrc', `~/.cshrc', and      
  `~/.gv'. Here `~' stands for the user's home directory.      
  Go to:      
  http://www.stud.uni-saarland.de/~anre0027/bug-report/.download-test.html.      
  Assume these are some lecture notes or just papers someone wants to      
  download, psnup(1) and print or just to take home on a zip disk (he/she      
  doesn't want to keep them on that computer, so they are downloaded into home      
  directory with the intention to erase them after that).      
  So you download these files into your home directory(*)      
  using the "save link (target) as" function.      
      
  The 3rd file is a .bashrc(**) file containing an echo statement and a touch      
  command.      
  Assume that your login shell is bash and you don't have your own .bashrc      
  file (which is likely if the system default suffices your needs).      
      
  In that case the download succeeds silently, no warning, in this      
  assumed(***) case not even a warning about overwriting will appear.      
  Even if .bashrc existed, the unattantive user might choose to overwrite it,      
  thinking it is the earlier version of lectures he/she downloaded before.      
      
  The code in .bashrc will be executed on next (interactive) shell start.      
  To see that just type bash in your xterm (or start another xterm).      
  You'll see the output of "echo YOU COULD HAVE BEEN EXPLOITED" although you      
  even didn't make the file executable.      
      
  One can hide the script completely by incorporating it into      
  another document and telling the web server to pass MIME type of another      
  document type to avoid the user to see the code on simple click, see sample      
  document 4, on this server without the MIME type forging.      
  You can forge the MIME type on your apache server by adding      
    application/pdf                 cshrc      
  to the mime.types file.      
  See      
  http://www.stud.uni-saarland.de/~anre0027/bug-report/.mimetype_forging.png.      
  to see that it works.      
  Once again not the mimetype forging or the Acrobat Reader accepting shell      
  code before document code is the problem. It only makes it even      
  more likely that the file will be downloaded.      
      
  The 5th file contains manipulated .gv file. Especially the uncompress      
  command might be interesting (executed automatically when you open .ps.gz      
  file) or the print command (but that one is shown before printing).      
  The .gv file is only an example for programs mentioned in 2) above.      
  They require one more step than 1), namely user executing those programs.      
      
(*) Home directory is the starting directory for downloads for most browsers.      
    Konqueror has Documents as its starting directory for downloads (so it is      
    a secure default), but the user might still choose to download into home      
    directory instead, since it is the first directory directly accessible      
    from (xterm or newly created KDE console) shell.      
      
(**) Source of the problem:      
     on most Linux/*BSD?/Solaris? systems user configuration files are      
     stored in home directory. They are denoted simply by prepending      
     a dot '.' in front of them which suppresses their appearance in "normal"      
     directory listing. They are called hidden files.      
     Most programs use hidden directories for their configuration files. Those      
     are not (directly) affected.      
      
(***) Actually on my Gentoo installation I didn't have a .bashrc file in my      
      home and I didn't care (it wasn't mentioned in the installation howto).      
      I only got to know that there are some defaults      
      in /etc/skel after I searched for .bashrc in the Gentoo bug database      
      to avoid duplicate bug report.      
      
Why this is a bad idea in general:      
- This might lead to exploits if the ordinary user      
  is unattentive for a moment, or      
- is new to Linux and thinks it is per se secure.      
- Simple downloading should not result in automatic delayed shell code      
  execution, since most users don't expect it.      
      
      
4. Impact      
=========      
  Arbitrary (delayed) code execution if user downloads files to home      
  directory and ignores the "strange" file name.      
      
      
5. Possible solutions      
=====================      
Mitigating the problem:      
----------------------      
Originally I thought that this would be the solution, but in my opinion,      
it only tries to cure the symptoms, not the cause, since .bashrc in home      
directory might get into user's way by other means, too, see 6.1 in full bug 
report (see link below). 
      
+ Prepend files that begin with a dot (and are to be downloaded into home      
  directory) with a prefix, e.g. "download(ed)".      
  For example if I download a file called .tcshrc (into home directory)      
  it becomes download.tcshrc per default.      
  Another positive aspect of this would be that the files would no longer      
  silently "disappear", since normally hidden files are not shown in      
  "Save as" dialogs or folder listings (provided we do that for all files and      
  not only for those that are to be downloaded into home directory).      
  An additional text on the dialog box/line(in w3m) might inform the user that      
  the file name was changed for security/usability reasons (perhaps with      
  additional option to deselect this prefix).      
      
- Heavy warning against downloading files that begin with a dot into home      
  directory which suggests as its default action to prefix it like described      
  above.      
  Problem: user sees warnings too often (leaving and entering https sites),      
           so it might be ignored or misunderstood.      
      
Solving the problem:      
-------------------      
+ Change OS configuration such that default user config directory is no longer      
  home directory, but something different, e.g. $(HOME)/.config, $(HOME)/.etc,      
  $(HOME)/etc or $(HOME)/Settings or whatever (that could then be determined      
  by an environment variable, e.g USER_CONFIG_DIR, ETC_HOME, HOME_ETC, ...).      
  Additional advantage: The home directory is not cluttered up any more by all      
  the config files and directories.      
  By the way it is not only me who dislike the cluttering of home directory      
  by the config files, I read about it in heise forums (it is in German),      
  see it also for examples how the environment variable could be called:      
       
http://www.heise.de/newsticker/foren/go.shtml?read=1&msg_id=6884384&forum_id=69124      
  Problem: - vendors and software developers would have to agree on the      
	     environment variable (or the directory) name      
	   - many programs would have to be changed      
	   - someone might choose, e.g. USER_CONFIG_DIR to be      
	     equal to HOME. In that case the problem persists!      
      
+ Change programs (or OS setup scripts?) to require the config files to be in      
  its own directory, e.g. $(HOME)/.bash/.bashrc instead of $(HOME)/.bashrc.      
  Problem: - users may ask why their .bashrc in home directory doesn't work      
	     any more, after all it used to work for years :)      
	   - that would require additional directories, increasing your file      
	     count in quota(1) :)      
      
Related problem: should the browser, etc still warn if the user enters config      
	directory by accident? At the moment user explicitly has to select      
	to see hidden files, so if the directory name begins with a dot we      
	have at least a secure default.      
	(The only program I use frequently that shows hidden files per default      
	is acroread. But that shouldn't be a problem, since if one wants to      
	"save as..." a downloaded document, the path points to a temporary      
	location and normally contains a prefixed version of the file name,      
	and even that one disappears if you click on one of the directories.)      
      
Bad solution:      
- Change programs that have config files that may be executed in such a way      
  that they require their config files to have execute bit to be set.      
  This would solve in particular the problem with .bashrc script.      
  Rationale: normally if you download a shell script you have to make it      
	     executable to be able to start it directly.      
  Problem: - this requires that the program that writes the file sets the      
	     umask/mode appropriately      
	   - it is often not directly visible if a config file might      
             be used to execute something unexpected or not      
	     (depends on the program that uses the config file).    
    
Some additional thoughts can be found in the full bug-report:   
http://www.stud.uni-saarland.de/~anre0027/bug-report/.bug-report.txt.   

Reproducible: Always

Steps to Reproduce:
1. Backup `~/.bashrc', `~/.cshrc', and `~/.gv'   
2. Go to:   
http://www.stud.uni-saarland.de/~anre0027/bug-report/.download-test.html.   
3. Right-click on "Sample document III" and select "Save Link Target As ...",   
and download this file to your home directory.   
4. Start an xterm or bash 
5. You see a message and a file named proof_of_concept.touch is touched in  
your current directory.  
  
Actual Results:  
.bashrc is downloaded without warning 

Expected Results:  
If you belong to people who think that having (shell) configuration files in    
home directory is the actual insecure default: then we should convince the  
others to think the same way, so that their programs put their config files  
into config directories,   
otherwise it is more secure to put (by default) a prefix into the files names 
that begin with a dot.

Comment 1

[Boris Zbarsky [:bzbarsky]]

Hmm... this is a serious issue, especially for Firefox's "don't prompt for
download location" setup.

I think I'd be OK with, on Unix, prefixing files starting with "." with
something.  We should certainly do it if we don't prompt for the download
location.  If we _do_ prompt for it, perhaps the default filename we offer
should be prefixed if that location is ${HOME}.  If the user then edits the
filename, that's the user's prerogative.

Comment 2

[[e-mail]]

The Suite currently doesn't default to any directory. If you enable the feature
via Preferences then there's an option to pick a default directory which for
better or worse defaults to the profile folder. Even if you enable the feature
by directly presetting browser.download.autoDownload to true it will still
prompt on the first download, although in this case it will default to the
filepicker default (which on gtk1 is the last opened else the home directory).

Comment 3

[Boris Zbarsky [:bzbarsky]]

Perhaps we need a separate bug on this for Firefox?

Comment 4

[Jesse Ruderman]

Do all magic configuration files on Linux have names starting with "."?

Comment 5

[Boris Zbarsky [:bzbarsky]]

Yes, unless they're in a directory whose name starts with '.'

Comment 6

[Andy]

A guy at Suse said there are some older X and Motif programs that use
~/Something instead of ~/.something, that is why he would advocate to change the
initial starting directory, but he would "not protect the user from himself by
using some kind of artificial intelligence or popups".
(He also mentioned that there is already a specification for the location of
configuration files:
http://standards.freedesktop.org/basedir-spec/latest/)

IMHO the problem would probably be solvable in a better way by creating some
rules for SELinux or GRsecurity, but policy-based security systems are not
standard on today's desktop systems (and hardly anyone installs them, me included).

Comment 7

[Mike Shaver (:shaver emeritus)]

Can someone file an equivalent bug against Firefox?

Comment 8

[Jesse Ruderman]

Filed bug 304345 for the same issue in Firefox.

Comment 9

[Jesse Ruderman]

See also bug 346994, "Remove leading dot (period) (.) from suggested filename for saving (save file)", which was filed on Mac but might become cross-platform.

Comment 10

[Daniel Veditz [:dveditz]]

We're checking in a fix for Firefox bug 346994 into rv:1.8.1.4 and rv:1.8.0.12 as our fix for bug 304345, the Firefox version of this bug. You may want to fix this in the suite in the same time-frame since that will expose the problem.

Comment 11

[Andy]

Does the fix also fix it for the mail part of Mozilla (do Mozilla (now Seamonkey) Browser and Mail have the same code for "Save as" functionality)?

I just came across RFC 1806 that describe the handling of attached files in mail user agents (like Mozilla Mail or Thunderbird), and even back in 1995 they consider it important to do some special handling for files like .login also for mail user agents. Do we consider it important? It is much less likely to be saved to home directory by an experienced user because the file name which is visible before choosing "Save as" is the real file name (not just a link name as is the case for a browser), however an inexperienced user might well do it (in spite of all the warnings not to even open files from unknown senders).

PS:
RFC 1806 (... - The Content-Disposition Header), Section 5 (Security Considerations):
[...]
Since this memo provides a way for the sender to suggest a filename,
   a receiving MUA must take care that the sender's suggested filename
   does not represent a hazard. Using UNIX as an example, some hazards
   would be:
          + Creating startup files (e.g., ".login").
          + Creating or overwriting system files (e.g.,
            "/etc/passwd").
          + Overwriting any existing file.
          + Placing executable files into any command search path
            (e.g., "~/bin/more").
          + Sending the file to a pipe (e.g., "| sh").
   In general, the receiving MUA should never name or place the file
   such that it will get interpreted or executed without the user
   explicitly initiating the action.
[...]

Comment 12

[Boris Zbarsky [:bzbarsky]]

The Save As code is not shared.

Comment 13

[Robert Kaiser]

We have EOLed SeaMonkey 1.x now, but we'll leave this bug closed so to not expose still-existing users of that series to a potential problem.
SeaMonkey 2.x uses the toolkit code that has been fixed by bug 304345.