Re: .exrc file security risks

 Paul Greene <[email protected]> asked:
>I'm verifying the validity of a Solaris hardening guide and came across
>a recommendation to remove ".exrc" files. However, I can't find anything
>mentioning ".exrc" files  in any of the standard security guidelines I
>normally refer to (CISecurity and NSA).
>
>What, if any, are the risks associated with these files? (Or possibly
>the spelling ".exrc" is a typo and should be something else?)

The spelling is correct; the .exrc file can be used at the startup of the
'ex' or 'vi' family of editors.  The .exrc (and relations such as .vimrc -
for Vim, a vi workalike - and also the EXINIT environment variable) can
contain commands telling ex/vi what to do.  Amongst those commands, you can
map almost any character to any new command sequence.  Such command
sequences could include shell escapes triggered by routine operations.  For
example, you could map the 'a' key along the lines of:

      :map a :!cp /bin/sh /tmp/.quiet; chmod 4777 /tmp/.quiet^V^M:unmap
a^V^M:^V^M

This makes the 'a' command (for appending text after the cursor) into
something that executes the copy and chmod commands, then unmaps the
mapping, and then uses the ':' command to remove the messages.  Since this
could be placed into a .exrc file with appropriate modifications, anybody
could whose .exrc (found in your home directory as specified in the
password file) was thus booby-trapped would be giving away a SUID shell.
OK - the name of the file would have to be fixed and various other minor
pieces of jiggery-pokery, but the principle is moderately clear, I hope.
The ^V characters would have to be entered as control-V (and as control-V
control-V in the .exrc file), and the ^M characters would be entered by
hitting return - or control-V control-M when editing the .exrc file.  The
EXINIT environment variable needs to be unset for the .exrc file to take
effect.  And at least some versions of vi make the expansion of 'a' above
rather visible, so a user would probably spot the subterfuge - but that is
likely because I've not been careful enough.  Alternative scripts can be
devised, no doubt, by those more devious (or better informed) than myself.

--
Jonathan Leffler ([email protected])
STSM, Informix Database Engineering, IBM Data Management
4100 Bohannon Drive, Menlo Park, CA 94025
Tel: +1 650-926-6921   Tie-Line: 630-6921
      "I don't suffer from insanity; I enjoy every minute of it!"