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: <Pine.SGI.4.44.0208271913020.203827-100000@hexeris> 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