From: aliver at xexil.com (aliver@...il.com)
Subject: Re: Take the trash-talker challenge!

On Tue, 27 Aug 2002, Steven M. Christey wrote:
> I suppose I'll pay for this dearly, but it was a nice little break
> from the daily grind.

Thanks for the excellent writeup Steve. I'll get right on it, this and
other issues will be corrected in the next version xxt. It doesn't buy you
root or beat the front door down on xxtea, but it is quite serious IMO. I
think I'll take the "wipe the env var after ciphering" approach not unlike
what I did with the key passed as an argument and not unlike your
suggestion.  The only thing I hated was being called a "vendor." *grin*
Since there is already a winner and since it doesn't really meet the
orginal terms of the Trash Talker Challenge, I hope you aren't going to
get pissed if I don't pay out on this one. However, if you were local I'd
buy you a beer or at least a shot of Stoli ;-)

aliver

> - Steve
>
> =======================================================================
>
> Vulnerability: if the passphrase is provided in an environment
> variable via the -g argument to xxt, then that variable is leaked
> during the encryption/decryption process, as demonstrated by the ps
> program.
>
> Impact: local users may steal the passphrases of other xxt users, then
> possibly decrypt the files, by monitoring active xxt processes on the
> system.
>
> Mitigating Factors: since xxt creates its output files mode 600, an
> attacker who has the passphrase still cannot decrypt files unless
> either (a) the victim must "leak" the file by changing its permissions
> or using an unencrypted medium to transfer the file, or (b) the
> attacker must compromise the account on which victim's files are
> stored.
>
> Affected versions: the version posted on Tuesday, August 27:
>   http://lists.netsys.com/pipermail/full-disclosure/2002-August/001472.html
>
> Affected platforms: at least Solaris 2.7, others may be vulnerable
> depending on how much process info is leaked to other users.
>
> There is also a bug in which a null pointer is copied if the specified
> environment variable is not defined, causing a core dump.  The
> security risks of this behavior were not explored.
>
>
> Demonstration
> -------------
>
> NOTE: A "sleep" call was inserted into the code so that the program
> would take longer to run, simulating the encryption/decryption of a
> large file.
>
>
> myhost{82}% unsetenv MYKEYPHRASE
> myhost{83}% ./xxt -e -i infile -o out -g MYKEYPHRASE
> Segmentation fault (core dumped)
> myhost{84}% setenv MYKEYPHRASE SEKRET
> myhost{85}% ./xxt -e -i infile -o out -g MYKEYPHRASE
> [SMC] Instrumented sleep for 10 seconds to facilitate env leak...
> ^Z
> Suspended
> myhost{86}% ps -eww|grep MYKEYPHRA
>   1300 pts/1    T  0:00 ./xxt -e -i infile -o out -g MYKEYPHRASE HOME=[blah] blah blah] PATH=[blah blah blah] ETC=blah ETC2=blah ... MYKEYPHRASE=SEKRET
>
>
> other@...ost{1}% whoami
> SomeBodyElse
> other@...ost{2}% ps -eww|grep MYKEYPHRA
>   1300 pts/1    T  0:00 ./xxt -e -i infile -o out -g MYKEYPHRASE HOME=[blah] blah blah] PATH=[blah blah blah] ETC=blah ETC2=blah ... MYKEYPHRASE=SEKRET
>
>
> Vulnerability Cause
> -------------------
>
> While the program is careful to wipe a local keyphrase variable
> shortly after its use, it does not clear the environment variable that
> originally held the keyphrase.
>
>
> Workarounds Available
> ---------------------
>
> Modify the use of xxt so that it does not use the -g option.
>
>
> Unofficial Solution
> -------------------
>
> To sharply reduce (but not eliminate) the window during which the
> passphrase is visible, the program could read the variable to 'getenv'
> immediately during option processing, clear the resulting string, and
> "unsetenv" the variable... or all variables.
>
> The following code works in Solaris 2.7.  There are probably bugs in
> it.
>
>             for(j=0;env[j] != NULL; j++)
>               {
>                 printf("ENV %s\n", env[j]);
>                 memset(env[j], '\0', strlen(env[j]));
>               }
>
>
> Vulnerability Disclosure Policy
> -------------------------------
>
> No compensation or credit is expected for discovery of this
> vulnerability.
>
> This vulnerability was released in accordance with the Responsible
> Disclosure Process draft.  Section 4.1, vendor policy, suggests that
> vendors publish information including what Grace Period the vendor
> wishes to observe, if any, before publishing details.
>
> The xxt vendor challenged the public to find a vulnerability that
> "would render a root shell when xxt is SUID root," with an implied
> Grace Period of 0 days.  Since this vulnerability is less severe than
> a root shell in general (at best it allows users to decrypt other
> users' files, which only potentially affects root), it is reasonable
> to follow the suggested 0 day Grace Period.
>
>
> Disclosure Timeline
> -------------------
>
> Discovery - Tuesday, August 27, 4 PM Eastern Daylight Time
> Publication - Tuesday, August 27, 6 PM Eastern Daylight Time
> _______________________________________________
> Full-Disclosure - We believe in it.
> Charter: http://lists.netsys.com/full-disclosure-charter.html
>

Powered by blists - more mailing lists