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
| ||
|
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