On Sat, Jan 31, 2015 at 4:40 PM, Chet Ramey <chet.ra...@case.edu> wrote:

> On 1/30/15 3:50 PM, Jonathan Hankins wrote:
> > I agree about being able to use named pipes, etc. as HISTFILE.  My
> concern
> > is that I think there may be a code path that leads to rename() and
> > open(O_TRUNC...) being called on something that isn't a regular file.
>
> OK, say the history file is not a regular file.  What negative scenarios
> are possible if the history library opens that file with O_TRUNC
>

​If the history code opens a block or char device file for append or
truncate, and writes to it, it could destroy the underlying file
structure.  I can't think of any reasonable scenario where HISTFILE could
be a block or char device, but like you said, named pipes could be useful.
Maybe test the file with S_ISREG|S_ISFIFO.
​


> > Furthermore, I think that if someone can manipulate a user's HISTFILE
> > setting maliciously, there may be a code path to cause an unwitting
> > overwrite of a file whose name ends in hyphen.
>
> If someone can manipulate a user's $HISTFILE setting, they can overwrite
> any file the user has permission to write.  It's always been thus.


​Right.  My concern is that a potential exploit could inject a malicious
value for HISTFILE into the environment.  I think (but may be wrong) that
HISTFILE is the only codepath in a default shell invocation that could
result in a silent writing to an arbitrary file without direct action on
the part of the user.  Good security practices are the responsibility of
the user, but I think it would be prudent to ensure that HISTFILE is, at
least a regular file, or a pipe.

-Jonathan Hankins


-- 
------------------------------------------------------------------------
Jonathan Hankins    Homewood City Schools

The simplest thought, like the concept of the number one,
has an elaborate logical underpinning. - Carl Sagan

jhank...@homewood.k12.al.us
------------------------------------------------------------------------

Reply via email to