lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <200208272234.SAA17740@linus.mitre.org>
From: coley at linus.mitre.org (Steven M. Christey)
Subject: Re: Take the trash-talker challenge!

I suppose I'll pay for this dearly, but it was a nice little break
from the daily grind.

- 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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ