On 6 December 2013 12:29, Andres Perera <andre...@zoho.com> wrote:
> On Fri, Dec 6, 2013 at 5:22 AM, Alexander Hall <alexan...@beard.se> wrote:
>> On 12/06/13 07:50, Andres Perera wrote:
>>>
>>> On Fri, Dec 6, 2013 at 1:58 AM, Jan Stary <h...@stare.cz> wrote:
>>>>
>>>> On Dec 05 19:09:05, andre...@zoho.com wrote:
>>>>>
>>>>> but then if the shell implementation uses tmpfiles for heredoc,
>>>>
>>>>
>>>> does it?
>>>
>>>
>>> ksh does:
>>>
>>> ~ $ :<<! &
>>>>
>>>> $(sleep 100)
>>>> !
>>>
>>> [1] 469
>>> ~ $ ls /tmp/sh*
>>> /tmp/shsWf2OXAO
>>>
>>> src/bin/ksh/exec.c r1.50:
>>>
>>>          /* Create temp file to hold content (done before newenv so temp
>>>           * doesn't get removed too soon).
>>>           */
>>>          h = maketemp(ATEMP, TT_HEREDOC_EXP, &e->temps);
>>>
>>>>
>>>>> and
>>>>> doesn't do the equivalent of rm -P, you have another leak you thought
>>>>> was taken care of
>>>>>
>>>>> conclusion: shell is not good for this
>>>>
>>>>
>>>> Yeah right.
>>>> Who would even think of doing this in shell.
>>>
>>>
>>> apparently at least one person did
>>>
>>> you aren't in sync with the quantity of real world shells that use
>>> temp files for heredoc, and who feature combinations of { printf
>>> (not)? being a builtin, alternatives like ``print'' and ``echo'' are
>>> unportable }
>>>
>>
>> You do point out some interesting apects. I've used the heredoc approach
>> without considering if my shell used tempfiles or not, but I'm usually
>> mostly concerned about stuff not going on the command line.
>>
>> However one decides for onself where to draw the line. There are probably
>> tons of leaks, even if you write your own code.
>>
>> X, xterm, vi, clipboard, ...
>
> yes, but this case is particularly insidious because i noticed that
> the original code went through the trouble of rm -P
>
> some people may have tmp as a memory backed fs and decide their uptime
> longevity is short enough, some people may have their entire fs's
> encrypted and decide that's enough
>
> that doesn't change the fact that modern password handling code
> doesn't transitively store cleartext secrets this way
>
> with C you can be very explicit about where you store and when you zero out
>

That does not mean this is going to happen though. Did you just
bzero() or memset()
a buffer where you had stored sensitive data ? It may not be enough. From the
compiler's point of view If you don't use the buffer afterwards, then
there is no to
call bzero() at all, so the call may be suppressed as part of optimisations.


> with shell it's easy to be clumsy in this particular domain
>
>>
>> /Alexander
>>
>>
>>>>
>>>>> even if it keeps heredocs in memory you have no idea if it zeros it
>>>>> out afterwards
>>>>>
>>>>> On Thu, Dec 5, 2013 at 6:57 PM, Andres Perera <andre...@zoho.com> wrote:
>>>>>>
>>>>>> On Thu, Dec 5, 2013 at 8:57 AM, Christian Weisgerber
>>>>>> <na...@mips.inka.de> wrote:
>>>>>>>
>>>>>>> Zé Loff <zel...@zeloff.org> wrote:
>>>>>>>
>>>>>>>> Not sure how advisable this is, but I'm using a gpg encrypted file,
>>>>>>>> which I keep somewhere hidden (just because). Just put them in file
>>>>>>>> foo and do 'gpg -e foo' (assuming you've already setup gpg). When you
>>>>>>>> need to look something up just do 'gpg -d foo' and the file gets
>>>>>>>> decrypted to stdout.
>>>>>>>
>>>>>>>
>>>>>>> *takes a deep breath*
>>>>>>>
>>>>>>> ~/bin/pwsafe
>>>>>>> --------------->
>>>>>>> #!/bin/sh
>>>>>>>
>>>>>>> SAFE=$HOME/.pwsafe
>>>>>>> TMPFILE=`mktemp /tmp/pwsafeXXXXXXXXXX` || exit 1
>>>>>>>
>>>>>>> trap 'rm -P "$TMPFILE"' 0 1 2 15
>>>>>>>
>>>>>>> STTY=`stty -g`
>>>>>>> echo -n "Password: "
>>>>>>> stty -echo
>>>>>>> read PASSWORD
>>>>>>> stty "$STTY"
>>>>>>>
>>>>>>> set -e
>>>>>>> echo -n "$PASSWORD" | openssl aes-256-cbc -d -in "$SAFE" -out
>>>>>>> "$TMPFILE" -pass stdin
>>>>>>
>>>>>>
>>>>>> this is tricky. some people will read and say ok i'll switch echo for
>>>>>> printf and get on w/my life
>>>>>>
>>>>>> printf not being a builtin, will show up in ps(1), and so will
>>>>>> $PASSWORD
>>>>>>
>>>>>> not apparent from the simple syntax used that such a change could end
>>>>>> up leaking important things
>>>>>>
>>>>>> it's better to use heredoc:
>>>>>>
>>>>>> openssl aes-256-cbc -d -in "$SAFE" -out "$TMPFILE" -pass stdin <<!
>>>>>> $PASSWORD
>>>>>> !
>>>>>>
>>>>>>> ${EDITOR-${VISUAL-vi}} "$TMPFILE"
>>>>>>> echo -n "$PASSWORD" | openssl aes-256-cbc -in "$TMPFILE" -out "$SAFE"
>>>>>>> -pass stdin
>>>>>>> <---------------
>>>>>>>
>>>>>>> --
>>>>>>> Christian "naddy" Weisgerber
>>>>>>> na...@mips.inka.de

Reply via email to