Re: RE: [Full-disclosure] XSS in Oracle default fcgi-bin/echo
Dear An, Referrer: scriptalert(1)/script Yes, but... seems not all echo's get a Referer passed to them. Cheers, Paul Paul Szabo p...@maths.usyd.edu.au http://www.maths.usyd.edu.au/u/psz/ School of Mathematics and Statistics University of SydneyAustralia
Security-Assessment.com Advisory: Oracle JRE - java.net.URLConnection class - Same-of-Origin (SOP) Policy Bypass
(, ) (,
. `.' ) ('.',
). , ('. ( ) (
(_,) .`), ) _ _,
/ _/ / _ \ _
\ \==/ /_\ \ _/ ___\/ _ \ / \
/ \/ |\\ \__( _ ) Y Y \
/__ /\___|__ / \___ /|__|_| /
\/ \/.-.\/ \/:wq
(x.0)
'=.|w|.='
_='```=.
presents..
Oracle JRE - java.net.URLConnection class –
Same-of-Origin (SOP) Policy Bypass
PDF:
http://www.security-assessment.com/files/advisories/Oracle_JRE_java_net_urlconnection_SOP_Bypass.pdf
CVE Identifier: http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=2010-3573
+---+
|Description|
+---+
Security-Assessment.com discovered that a Java Applet
making use of java.net.URLConnection class can be used
to bypass same-of-origin (SOP) policy and domain based
security controls in modern browsers when communication
occurs between two domains that resolve to the same IP
address. This advisory includes a Proof-of-Concept
(PoC) demo and a Java Applet source code, which
demonstrates how this security can be exploited to leak
cookie information to an unauthorised domain, which
resides on the same host IP address.
++
|Exploitation|
++
The Flash movie demo can be viewed at the following
link:
http://www.security-assessment.com/files/advisories/java_net_urlconnection_sop_bypass_demo.swf
Proof of Concept (PoC) in demo demonstrates that a
Cross Site Request Forgery (XSRF) attack can be leveraged
by using a Java Applet which implements the
java.net.URLConnection class. Traditionally, XSRF is used
to force a user to perform an unwanted action on a target
web site. In this case, the PoC shows that XSRF can be
used to capture sensitive information such as cookie
associated to a target web site.
The following assumptions are made in this PoC:
1. Virtual hosts www.targetsite.net and
www.badsite.com resolve to the same IP address;
2. Malicious user controls www.badsite.com web site;
3. Malicious user targets www.targetsite.net users.
The following list summarises the sequence of actions
shown in the demo:
1. User has a valid cookie for www.targetsite.net
2. The same user visits www.badsite.com which performs
a cross site forged request to www.targetsite.net .
The forged request is performed by a Java Applet
embedded on the malicious site. The Java Applet
bypasses the Same-of-Origin policy as an unsigned Java
Applet should not be able to communicate
from www.badsite.com to www.targetsite.net without
a crossdomain.xml policy file.
3. Java Applet performs first GET request to
www.targetsite.net. At this stage, the Java Applet
controls the Cookie: header sent to www.targetsite.net
through the getRequestProperty(cookie) method.
This is in breach with SOP.
4. A second request is done for the purpose
of the demo which leaks www.targetsite.net
cookie’s to www.badsite.com via an HTTP GET
request.
Testing was successfully performed using Java(TM)
SE Runtime Environment (build 1.6.0_21-b07) and the
following browsers:
- Mozilla Firefox 3.5.8 (Windows XP)
- Opera 10.60 (Windows XP)
- Internet Explorer 6.0.2900.5512 (Windows XP)
- Google Chrome 5.0.375.9 (Windows XP)
- Internet Explorer 8.0.6001.18702 (Windows XP)
- Safari 5.0 (7533.16) (Windows XP)
The Java Applet source code used in the demo can be
downloaded at the following link:
http://www.security-assessment.com/files/advisories/MaliciousJavaApplet.zip
++
|Solution|
++
Security-Assessment.com follows responsible disclosure
and promptly contacted Oracle after discovering
the issue. Oracle was contacted on August 1,
2010.
Oracle has created a fix for this vulnerability which
has been included as part of Critical Patch Update
Advisory - October 2010. Security-Assessment.com
recommends all users of JRE and JDK to upgrade to
the latest version as soon as possible.
For more information on the new release of JRE/JDK
please refer to the link:
http://www.oracle.com/technetwork/java/javase/downloads/index.html
+--+
|Credit|
+--+
Discovered and advised to Oracle
August 2010 by Roberto Suggi Liverani of
Security-Assessment.com.
Personal site: http://malerisch.net
+-+
|Extra|
+-+
Another interesting attack was discovered as part
of the research on this vulnerability.
This attack is another example of leveraging XSRF
with the potential of leaking cookie, basic and digest
authentication tokens using Java Applet and the
Compability with older browser feature in
Apache Web Server.
For a PDF version of this research please follow the link below:
http://www.security-assessment.com/files/whitepapers/Leveraging_XSRF_with_Apache_Web_Server_Compatibility_with_older_browser_feature_and_Java_Applet.pdf
+-+
|About Security-Assessment.com|
+-+
Security-Assessment.com is a New Zealand based world
leader in web
H2HC Cancun - Registrations are open
Dear Lists, I'm happy (and proud) to announce that the registrations for H2HC Cancun are finally available online. This is the first year of the conference in Cancun/Mexico (on 3rd of december) and the 7th year of the Conference in São Paulo/Brazil (on 27-28 of november). We are growing fast and we are happy to have the support of organizations such as Microsoft, Check Point, Nitro Security, Trend Micro, Symantec, Secureworks, iDefense, Core Security, Immunity Security, Trustwave, Tenable and many local companies like Secure1 and Conviso. Hope to see you around, Rodrigo (BSDaemon).
Re: [Full-disclosure] XSS in Oracle default fcgi-bin/echo
Dear Riyaz,
The mere mention of fcgi-bin/echo in your first mail is enough for anybody
to derive the PoC. Here's what I found in under a minute:
*/fcgi-bin/echo/scriptaler('xss')/script*
Sorry, that is a different issue: the one you mention was patched by
Oracle a long time ago. (All the fcgi-bin/echo that I tested, were
already patched against the one you mention, but vulnerable to that
other I found.)
Cheers, Paul
Paul Szabo p...@maths.usyd.edu.au http://www.maths.usyd.edu.au/u/psz/
School of Mathematics and Statistics University of SydneyAustralia
[USN-1005-1] poppler vulnerabilities
=== Ubuntu Security Notice USN-1005-1 October 19, 2010 poppler vulnerabilities CVE-2010-3702, CVE-2010-3703, CVE-2010-3704 === A security issue affects the following Ubuntu releases: Ubuntu 6.06 LTS Ubuntu 8.04 LTS Ubuntu 9.04 Ubuntu 9.10 Ubuntu 10.04 LTS Ubuntu 10.10 This advisory also applies to the corresponding versions of Kubuntu, Edubuntu, and Xubuntu. The problem can be corrected by upgrading your system to the following package versions: Ubuntu 6.06 LTS: libpoppler1 0.5.1-0ubuntu7.8 libpoppler1-glib0.5.1-0ubuntu7.8 Ubuntu 8.04 LTS: libpoppler-glib20.6.4-1ubuntu3.5 libpoppler2 0.6.4-1ubuntu3.5 Ubuntu 9.04: libpoppler-glib40.10.5-1ubuntu2.6 libpoppler4 0.10.5-1ubuntu2.6 Ubuntu 9.10: libpoppler-glib40.12.0-0ubuntu2.3 libpoppler5 0.12.0-0ubuntu2.3 Ubuntu 10.04 LTS: libpoppler-glib40.12.4-0ubuntu5.1 libpoppler5 0.12.4-0ubuntu5.1 Ubuntu 10.10: libpoppler-glib50.14.3-0ubuntu1.1 libpoppler7 0.14.3-0ubuntu1.1 In general, a standard system update will make all the necessary changes. Details follow: It was discovered that poppler contained multiple security issues when parsing malformed PDF documents. If a user or automated system were tricked into opening a crafted PDF file, an attacker could cause a denial of service or execute arbitrary code with privileges of the user invoking the program. Updated packages for Ubuntu 6.06 LTS: Source archives: http://security.ubuntu.com/ubuntu/pool/main/p/poppler/poppler_0.5.1-0ubuntu7.8.diff.gz Size/MD5:27259 bedbca4c7d1fbb131e87ac7d01b9ccfb http://security.ubuntu.com/ubuntu/pool/main/p/poppler/poppler_0.5.1-0ubuntu7.8.dsc Size/MD5: 2375 9242a34c31aec338034bad41ff0e04fb http://security.ubuntu.com/ubuntu/pool/main/p/poppler/poppler_0.5.1.orig.tar.gz Size/MD5: 954930 a136cd731892f4570933034ba97c8704 amd64 architecture (Athlon64, Opteron, EM64T Xeon): http://security.ubuntu.com/ubuntu/pool/main/p/poppler/libpoppler-dev_0.5.1-0ubuntu7.8_amd64.deb Size/MD5: 729804 990c4697220246f06734ec985bf79805 http://security.ubuntu.com/ubuntu/pool/main/p/poppler/libpoppler-glib-dev_0.5.1-0ubuntu7.8_amd64.deb Size/MD5:58242 4e17049f4d461125928bd33eb905542e http://security.ubuntu.com/ubuntu/pool/main/p/poppler/libpoppler-qt-dev_0.5.1-0ubuntu7.8_amd64.deb Size/MD5:47402 2e1911778f8d114dc01570a16cc753fa http://security.ubuntu.com/ubuntu/pool/main/p/poppler/libpoppler1-glib_0.5.1-0ubuntu7.8_amd64.deb Size/MD5:52998 4dc5f9471611f96ec0bfb5314a527d67 http://security.ubuntu.com/ubuntu/pool/main/p/poppler/libpoppler1-qt_0.5.1-0ubuntu7.8_amd64.deb Size/MD5:43618 37459b85fdf031fdba6e1b35ea116679 http://security.ubuntu.com/ubuntu/pool/main/p/poppler/libpoppler1_0.5.1-0ubuntu7.8_amd64.deb Size/MD5: 546536 7ad7ef20bd092f9007a0a4f2920d301d http://security.ubuntu.com/ubuntu/pool/main/p/poppler/poppler-utils_0.5.1-0ubuntu7.8_amd64.deb Size/MD5: 101316 389d8b7bf42dd291ae246bbe5306c66e i386 architecture (x86 compatible Intel/AMD): http://security.ubuntu.com/ubuntu/pool/main/p/poppler/libpoppler-dev_0.5.1-0ubuntu7.8_i386.deb Size/MD5: 664928 8670a45be74a527aa2381c786d6f499c http://security.ubuntu.com/ubuntu/pool/main/p/poppler/libpoppler-glib-dev_0.5.1-0ubuntu7.8_i386.deb Size/MD5:56038 20fa91b22991fbf8f2855d0019a30066 http://security.ubuntu.com/ubuntu/pool/main/p/poppler/libpoppler-qt-dev_0.5.1-0ubuntu7.8_i386.deb Size/MD5:46100 aa511d2877d5a86ee35fb8760168e746 http://security.ubuntu.com/ubuntu/pool/main/p/poppler/libpoppler1-glib_0.5.1-0ubuntu7.8_i386.deb Size/MD5:51888 e635377fcd0afcc86fb5665f12596940 http://security.ubuntu.com/ubuntu/pool/main/p/poppler/libpoppler1-qt_0.5.1-0ubuntu7.8_i386.deb Size/MD5:43120 0a299604034207977e6549719e97c3bb http://security.ubuntu.com/ubuntu/pool/main/p/poppler/libpoppler1_0.5.1-0ubuntu7.8_i386.deb Size/MD5: 505126 546b78451a3db468d906a13c3e461755 http://security.ubuntu.com/ubuntu/pool/main/p/poppler/poppler-utils_0.5.1-0ubuntu7.8_i386.deb Size/MD5:93028 075e41dd3d3608e7e4a5f682d3ab0d45 powerpc architecture (Apple Macintosh G3/G4/G5): http://security.ubuntu.com/ubuntu/pool/main/p/poppler/libpoppler-dev_0.5.1-0ubuntu7.8_powerpc.deb Size/MD5: 769490 69fe73d00ba079febc5ada96e82cb518 http://security.ubuntu.com/ubuntu/pool/main/p/poppler/libpoppler-glib-dev_0.5.1-0ubuntu7.8_powerpc.deb Size/MD5:60272 ef55f2b86d376cfc7f81786fa56f0852
[USN-1006-1] WebKit vulnerabilities
=== Ubuntu Security Notice USN-1006-1 October 19, 2010 webkit vulnerabilities https://launchpad.net/bugs/660075 === A security issue affects the following Ubuntu releases: Ubuntu 9.10 Ubuntu 10.04 LTS Ubuntu 10.10 This advisory also applies to the corresponding versions of Kubuntu, Edubuntu, and Xubuntu. The problem can be corrected by upgrading your system to the following package versions: Ubuntu 9.10: libwebkit-1.0-2 1.2.5-0ubuntu0.9.10.1 Ubuntu 10.04 LTS: libwebkit-1.0-2 1.2.5-0ubuntu0.10.04.1 Ubuntu 10.10: libwebkit-1.0-2 1.2.5-0ubuntu0.10.10.1 After a standard system update you need to restart any applications that use WebKit, such as Epiphany and Midori, to make all the necessary changes. Details follow: A large number of security issues were discovered in the WebKit browser and JavaScript engines. If a user were tricked into viewing a malicious website, a remote attacker could exploit a variety of issues related to web browser security, including cross-site scripting attacks, denial of service attacks, and arbitrary code execution. Please consult the bug listed at the top of this advisory to get the exact list of CVE numbers fixed for each release. Updated packages for Ubuntu 9.10: Source archives: http://security.ubuntu.com/ubuntu/pool/main/w/webkit/webkit_1.2.5-0ubuntu0.9.10.1.diff.gz Size/MD5:28902 3436d9c6218a4cd1a5754b26d0f6e256 http://security.ubuntu.com/ubuntu/pool/main/w/webkit/webkit_1.2.5-0ubuntu0.9.10.1.dsc Size/MD5: 2346 9cc885388210502d79ca6655e073f05e http://security.ubuntu.com/ubuntu/pool/main/w/webkit/webkit_1.2.5.orig.tar.gz Size/MD5: 6727977 09f04985665b9abf6f0d9956f86a6a31 Architecture independent packages: http://security.ubuntu.com/ubuntu/pool/main/w/webkit/libwebkit-1.0-common_1.2.5-0ubuntu0.9.10.1_all.deb Size/MD5: 615320 20d3e7adda2f5fa5a142a4501280a837 amd64 architecture (Athlon64, Opteron, EM64T Xeon): http://security.ubuntu.com/ubuntu/pool/main/w/webkit/libwebkit-1.0-2-dbg_1.2.5-0ubuntu0.9.10.1_amd64.deb Size/MD5: 139134580 8d73bb5f05a99b76445655c0aff9eb12 http://security.ubuntu.com/ubuntu/pool/main/w/webkit/libwebkit-1.0-2_1.2.5-0ubuntu0.9.10.1_amd64.deb Size/MD5: 5751420 31eda9fa73766cef54571ecab5f2c6e0 http://security.ubuntu.com/ubuntu/pool/main/w/webkit/libwebkit-dev_1.2.5-0ubuntu0.9.10.1_amd64.deb Size/MD5: 118264 4402376e41a392f18ec26b102a27c4aa i386 architecture (x86 compatible Intel/AMD): http://security.ubuntu.com/ubuntu/pool/main/w/webkit/libwebkit-1.0-2-dbg_1.2.5-0ubuntu0.9.10.1_i386.deb Size/MD5: 138270646 ff3700bd6053f18209c8884d0bdc5bc4 http://security.ubuntu.com/ubuntu/pool/main/w/webkit/libwebkit-1.0-2_1.2.5-0ubuntu0.9.10.1_i386.deb Size/MD5: 5140872 73f89219225b633f4a866245712e6837 http://security.ubuntu.com/ubuntu/pool/main/w/webkit/libwebkit-dev_1.2.5-0ubuntu0.9.10.1_i386.deb Size/MD5: 115628 aa55bd17bfd68286f34a8aac9017839d lpia architecture (Low Power Intel Architecture): http://ports.ubuntu.com/pool/main/w/webkit/libwebkit-1.0-2-dbg_1.2.5-0ubuntu0.9.10.1_lpia.deb Size/MD5: 138495338 f45c9ce9a707fbcf9cf17d3039e9a47f http://ports.ubuntu.com/pool/main/w/webkit/libwebkit-1.0-2_1.2.5-0ubuntu0.9.10.1_lpia.deb Size/MD5: 5093272 11a6dd088bde3429ed8bd8e4bd0c2610 http://ports.ubuntu.com/pool/main/w/webkit/libwebkit-dev_1.2.5-0ubuntu0.9.10.1_lpia.deb Size/MD5: 115612 d3440a9475264109fe7ee7806ad1659b powerpc architecture (Apple Macintosh G3/G4/G5): http://ports.ubuntu.com/pool/main/w/webkit/libwebkit-1.0-2-dbg_1.2.5-0ubuntu0.9.10.1_powerpc.deb Size/MD5: 138840804 c0d644f5609bb659e5c934725bfa862d http://ports.ubuntu.com/pool/main/w/webkit/libwebkit-1.0-2_1.2.5-0ubuntu0.9.10.1_powerpc.deb Size/MD5: 5405430 04557727a3bac6037caca9b717b8e218 http://ports.ubuntu.com/pool/main/w/webkit/libwebkit-dev_1.2.5-0ubuntu0.9.10.1_powerpc.deb Size/MD5: 115620 916e4e0e1bf105f62c6d3ef2756d1186 sparc architecture (Sun SPARC/UltraSPARC): http://ports.ubuntu.com/pool/main/w/webkit/libwebkit-1.0-2-dbg_1.2.5-0ubuntu0.9.10.1_sparc.deb Size/MD5: 137354182 d0fd14e1622fcacfa5f2f97c40bfcacc http://ports.ubuntu.com/pool/main/w/webkit/libwebkit-1.0-2_1.2.5-0ubuntu0.9.10.1_sparc.deb Size/MD5: 6022530 ccf509a6bc5d3085170c8652323f154a http://ports.ubuntu.com/pool/main/w/webkit/libwebkit-dev_1.2.5-0ubuntu0.9.10.1_sparc.deb Size/MD5: 115604 279ec84c70acc2f0f6ac757d8ea8314d Updated packages for Ubuntu 10.04 LTS: Source archives: http://security.ubuntu.com/ubuntu/pool/main/w/webkit/webkit_1.2.5-0ubuntu0.10.04.1.debian.tar.gz Size/MD5:28130 d8f8ce4ec546bf31939df7fb25f0546e
The GNU C library dynamic linker expands $ORIGIN in setuid library search path
The GNU C library dynamic linker expands $ORIGIN in setuid library search path
--
Gruezi, This is CVE-2010-3847.
The dynamic linker (or dynamic loader) is responsible for the runtime linking of
dynamically linked programs. ld.so operates in two security modes, a permissive
mode that allows a high degree of control over the load operation, and a secure
mode (libc_enable_secure) intended to prevent users from interfering with the
loading of privileged executables.
$ORIGIN is an ELF substitution sequence representing the location of the
executable being loaded in the filesystem hierarchy. The intention is to allow
executables to specify a search path for libraries that is relative to their
location, to simplify packaging without spamming the standard search paths with
single-use libraries.
Note that despite the confusing naming convention, $ORIGIN is specified in a
DT_RPATH or DT_RUNPATH dynamic tag inside the executable itself, not via the
environment (developers would normally use the -rpath ld parameter, or
-Wl,-rpath,$ORIGIN via the compiler driver).
The ELF specification suggests that $ORIGIN be ignored for SUID and SGID
binaries,
http://web.archive.org/web/20041026003725/http://www.caldera.com/developers/gabi/2003-12-17/ch5.dynamic.html#substitution
For security, the dynamic linker does not allow use of $ORIGIN substitution
sequences for set-user and set-group ID programs. For such sequences that
appear within strings specified by DT_RUNPATH dynamic array entries, the
specific search path containing the $ORIGIN sequence is ignored (though other
search paths in the same string are processed). $ORIGIN sequences within a
DT_NEEDED entry or path passed as a parameter to dlopen() are treated as
errors. The same restrictions may be applied to processes that have more than
minimal privileges on systems with installed extended security mechanisms.
However, glibc ignores this recommendation. The attack the ELF designers were
likely concerned about is users creating hardlinks to suid executables in
directories they control and then executing them, thus controlling the
expansion of $ORIGIN.
It is tough to form a thorough complaint about this glibc behaviour however,
as any developer who believes they're smart enough to safely create suid
programs should be smart enough to understand the implications of $ORIGIN
and hard links on load behaviour. The glibc maintainers are some of the
smartest guys in free software, and well known for having a no hand-holding
stance on various issues, so I suspect they wanted a better argument than this
for modifying the behaviour (I pointed it out a few years ago, but there was
little interest).
However, I have now discovered a way to exploit this. The origin expansion
mechanism is recycled for use in LD_AUDIT support, although an attempt is made
to prevent it from working, it is insufficient.
LD_AUDIT is intended for use with the linker auditing api (see the rtld-audit
manual), and has the usual restrictions for setuid programs as LD_PRELOAD does.
However, $ORIGIN expansion is only prevented if it is not used in isolation.
The codepath that triggers this expansion is
_dl_init_paths() - _dl_dst_substitute() - _is_dst()
(in the code below DST is dynamic string token)
http://sourceware.org/git/?p=glibc.git;a=blob;f=elf/dl-load.c;h=a7162eb77de7a538235a4326d0eb9ccb5b244c01;hb=HEAD#l741
741 /* Expand DSTs. */
742 size_t cnt = DL_DST_COUNT (llp, 1);
743 if (__builtin_expect (cnt == 0, 1))
744 llp_tmp = strdupa (llp);
745 else
746 {
747 /* Determine the length of the substituted string. */
748 size_t total = DL_DST_REQUIRED (l, llp, strlen (llp), cnt);
749
750 /* Allocate the necessary memory. */
751 llp_tmp = (char *) alloca (total + 1);
752 llp_tmp = _dl_dst_substitute (l, llp, llp_tmp, 1);
753 }
http://sourceware.org/git/?p=glibc.git;a=blob;f=elf/dl-load.c;h=a7162eb77de7a538235a4326d0eb9ccb5b244c01;hb=HEAD#l245
253 if (__builtin_expect (*name == '$', 0))
254 {
255 const char *repl = NULL;
256 size_t len;
257
258 ++name;
259 if ((len = is_dst (start, name, ORIGIN, is_path,
260 INTUSE(__libc_enable_secure))) != 0)
261 {
...
267 repl = l-l_origin;
268 }
http://sourceware.org/git/?p=glibc.git;a=blob;f=elf/dl-load.c;h=a7162eb77de7a538235a4326d0eb9ccb5b244c01;hb=HEAD#l171
202 if (__builtin_expect (secure, 0)
203((name[len] != '\0' (!is_path || name[len] != ':'))
204 || (name != start + 1 (!is_path || name[-2] != ':'
205 return 0;
206
207 return len;
208 }
As you can see, $ORIGIN is only expanded if it is alone and first in the path.
This makes little sense, and does not appear to be useful even if
Re: Insecure SMS authorization scheme at LiqPAY micro-payments of PrivatBank (Ukraine)
Hello Andriy and Bugtraq! It's interesting issue in LiqPAY. Which was quickly fixed by Privat Bank after your disclosure. Even if they denied to fix it (as not issue in their opinion) at 22 March 2010, when you officially informed them, already at 27 March 2010 they fixed it, by adding site's address into the text of sms. Even at 11 March 2010 they changed their default text of sms and added into it the suggestion to not pass password to third party. All these changes will not eliminate all forms of phishing, but still is an improvement of sms-message. So there was an effect from your informing and disclosing of this vulnerability ;-) and Privat Bank fixed it. This is that rare case when they fixed the holes which they were warned about. Because they ignored all my warnings to Privat Bank during 2008-2010 about multiple vulnerabilities at many of their sites (and so didn't answer and didn't fix the holes). Also interesting that this issue is similar to one of issues of Privat Bank's Privat24 for Facebook, which you disclosed recently (http://lists.grok.org.uk/pipermail/full-disclosure/2010-October/076834.html). And if they fixed issue with sms in case of LiqPAY, then they didn't fixed it in case of Facebook version of Privat24. Which is strange, because they could quickly fixed text of that sms-messages, as they early did for their LiqPAY system. Best wishes regards, MustLive Administrator of Websecurity web site http://websecurity.com.ua Insecure SMS authorization scheme at LiqPAY micro-payments of PrivatBank (Ukraine) Mar 22 2010 05:38PM Andriy Tereshchenko (tag 24 odessa ua) 1) Affected Service * LiqPAY micro-payment system from PrivatBank, Ukraine 2) Severity Rating: Moderate (need user actions) Impact: Exposure of sensitive financial information and unauthorized access to system Where: Remote (man-in-the-middle)
VSR Advisories: Linux RDS Protocol Local Privilege Escalation
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 VSR Security Advisory http://www.vsecurity.com/ - -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Advisory Name: Linux RDS Protocol Local Privilege Escalation Release Date: 2010-10-19 Application: Linux Kernel Versions: 2.6.30 - 2.6.36-rc8 Severity: High Author: Dan Rosenberg drosenberg (at) vsecurity (dot) com Vendor Status: Patch Released [3] CVE Candidate: CVE-2010-3904 Reference: http://www.vsecurity.com/resources/advisory/20101019-1/ - -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Product Description - --- - From [1]: Linux is a free Unix-type operating system originally created by Linus Torvalds with the assistance of developers around the world. Developed under the GNU General Public License, the source code for Linux is freely available to everyone. - From [2]: Reliable Datagram Sockets (RDS) provide in order, non-duplicating, highly available, low overhead, reliable delivery of datagrams between hundreds of thousands of non-connected endpoints. Vulnerability Overview - -- On October 13th, VSR identified a vulnerability in the RDS protocol, as implemented in the Linux kernel. Because kernel functions responsible for copying data between kernel and user space failed to verify that a user-provided address actually resided in the user segment, a local attacker could issue specially crafted socket function calls to write abritrary values into kernel memory. By leveraging this capability, it is possible for unprivileged users to escalate privileges to root. Vulnerability Details - - On Linux, recvmsg() style socket calls are performed using iovec structs, which allow a user to specify a base address and size for a buffer used to receive socket data. Each packet family is responsible for defining functions that copy socket data, which is received by the kernel, back to user space to allow user programs to process and handle received network data. When performing this copying of data to user space, the RDS protocol failed to verify that the base address of a user-provided iovec struct pointed to a valid userspace address before using the __copy_to_user_inatomic() function to copy the data. As a result, by providing a kernel address as an iovec base and issuing a recvmsg() style socket call, a local user could write arbitrary data into kernel memory. This can be leveraged to escalate privileges to root. Proof-of-Concept Exploit - VSR has developed a proof-of-concept exploit [4] to both demonstrate the severity of this issue as well as allow users and administrators to verify the existence of the vulnerability. The exploit leverages the ability to write into kernel memory to reset the kernel's security operations structure and gain root privileges. The exploit requires that kernel symbol resolution is available to unprivileged users, via /proc/kallsyms or similar, as is the case on most stock distributions. It has been tested on both 32-bit and 64-bit x86 platforms. While this exploit has been reliable during testing, it is not advised to run kernel exploits on production systems, as there is a risk of causing system instability and crashing the affected machine. Versions Affected - - This vulnerability affects unpatched versions of the Linux kernel, starting from 2.6.30, where the RDS protocol was first included. Installations are only vulnerable if the CONFIG_RDS kernel configuration option is set, and if there are no restrictions on unprivileged users loading packet family modules, as is the case on most stock distributions. Vendor Response - --- The following timeline details Linux's response to the reported issue. 2010-10-13Vulnerability reported to Linux security team 2010-10-13Response, agreement on disclosure date 2010-10-19Fix publicly committed [3] 2010-10-19Coordinated disclosure Recommendation - -- Users should either install updates provided by downstream distributions, or apply the committed patch [3] and recompile their kernel. Common Vulnerabilities and Exposures (CVE) Information - -- The Common Vulnerabilities and Exposures (CVE) project has assigned the number CVE-2010-3904 to this issue. This is a candidates for inclusion in the CVE list (http://cve.mitre.org), which standardizes names for security problems. Acknowledgements - Thanks to Andrew Morton, Linus Torvalds, Andy Grover, and Eugene Teo for their prompt responses and patch. - -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- References: 1. Linux kernel http://www.linux.org 2. Reliable Datagram Sockets http://oss.oracle.com/pipermail/rds-devel/2007-November
