XADV-2013003 Linux Kernel fbdev Driver arcfb_write() Overflow
++
| XADV-2013003 Linux Kernel fbdev Driver arcfb_write() Overflow |
++
Vulnerable versions:
- linux kernel 3.12 =
- linux kernel 2.6.x
Testbed: linux kernel 2.6.18
Type: Local
Impact: Kernel Panic
Vendor: http://www.x90c.org
Author: x90c geinblues *nospam* gmail dot com
Site: x90c.org
=
ABSTRACT:
=
The fbdev driver is frame buffer driver for arc monochrome lcd
board in the linux kernel.
The linux kernel driver has a overflow vulnerability because
the codes at arcfb_write(). When if large value as the parameter
to the arcfb_write() it will be overflow to lead the kernel panic.
The large 0x copy_from_user() lead to the kernel panic. [1]
* references:
[1] http://www.securityfocus.com/archive/1/362953/30/0/threaded
[2] http://zerryloveyou.blog.com/2010/12/27/linux-lcd-driver-writing/
[3] http://grsecurity.net/~spender/changelog-stable2-latest.txt
[4] http://grsecurity.net/~spender/changelog-stable2vserver.txt
=
DETAILS:
=
1. Vulnerable arcfb_write()
Arbitrary user can control count, ppos variable both. The ppos must
not be larger value than fbmemlength variable (exp cond 3) and
the count + p also not be larger than fbmemlength (exp cond 4).
a little value p, large value to 0x count can be reached
the copy_from_user(). 0x bytes copied and kernel panic!
[linux-2.6.18-kdb/drivers/video/arcfb.c]
/*
* this is the access path from userspace. they can seek and write to
* the fb. it's inefficient for them to do anything less than 64*8
* writes since we update the lcd in each write() anyway.
*/
static ssize_t arcfb_write(struct file *file, const char __user *buf, size_t
count,
loff_t *ppos) // XXX unsigned count If exp cond 1)
count==0x
{
/* modded from epson 1355 */
struct inode *inode;
int fbidx;
struct fb_info *info;
unsigned long p;// unsigned long.
int err=-EINVAL;
unsigned int fbmemlength,x,y,w,h, bitppos, startpos, endpos, bitcount;
struct arcfb_par *par;
unsigned int xres;
p = *ppos; // XXX p = *ppos If exp cond2) p=0xfff
inode = file-f_dentry-d_inode;
fbidx = iminor(inode);
info = registered_fb[fbidx]; // XXX info = registered frame buffer.
if (!info || !info-screen_base)
return -ENODEV;
par = info-par;
xres = info-var.xres;
fbmemlength = (xres * info-var.yres)/8;
if (p fbmemlength) // If exp cond3) fbmemlength 0xfff.
return -ENOSPC;
err = 0;
/* XXX exp cond 4) 0x+0xfff=0xffe fbmemlength? no. */
if ((count + p) fbmemlength) {
count = fbmemlength - p;
err = -ENOSPC;
}
if (count) { // XXX count?
char *base_addr;
base_addr = info-screen_base;
count -= copy_from_user(base_addr + p, buf, count); // XXX 0x
bytes copied. (kernel panic!)
..
}
static struct fb_ops arcfb_ops = {
.owner = THIS_MODULE,
.fb_open= arcfb_open,
.fb_write = arcfb_write, // arcfb_write() for the driver's write.
.fb_release = arcfb_release,
.fb_pan_display = arcfb_pan_display,
.fb_fillrect= arcfb_fillrect,
.fb_copyarea= arcfb_copyarea,
.fb_imageblit = arcfb_imageblit,
.fb_ioctl = arcfb_ioctl,
};
2. fb_info struct.
struct fb_info {
int node;
..
char __iomem *screen_base; /* Virtual address */
unsigned long screen_size; /* Amount of ioremapped VRAM or 0 */ XXX
void *pseudo_palette; /* Fake palette of 16 colors */
#define FBINFO_STATE_RUNNING0
#define FBINFO_STATE_SUSPENDED 1
u32 state; /* Hardware state i.e suspend */
void *fbcon_par;/* fbcon use-only private area */
/* From here on everything is device dependent */
void *par;
};
base_addr variable to copy dest pointer is the char __iomem *.
and it can be overflowed.
===
EXPLOIT CODES:
===
-
=
PATCH CODES:
=
-
===
VENDOR STATUS:
===
2013/11/10 - I discovered the vulnerability.
2013/11/11 - The advisory released.
2013/11/11 - grsecurity spender's commit.
(http://grsecurity.net/~spender/changelog-stable2-latest.txt)
DISCLAIMER:
The authors reserve the right not to be responsible for the topicality,
correctness, completeness or quality of the information provided in this
document. Liability claims regarding damage caused by the use of any information
provided, including any kind of information which is incomplete or incorrect,
will therefore be rejected.
XADV-2013008 Linux Kernel 3.11.7 = sk_attach_filter Kernel Heap Corruption
+---+
| XADV-2013008 Linux Kernel 3.11.7 = sk_attach_filter Kernel Heap Corruption
|
+---+
Vulnerable versions:
- linux kernel 3.11.7 =
Testbed: ubuntu
Type: Local
Impact: Medium
Vendor: http://www.kernel.org
Author: x90c geinblues *nospam* gmail dot com
Site: x90c.org
=
ABSTRACT:
=
The Linux Socket Filtering is derived from the Berkeley Packet Filter.
There are some distinct differences between the BSD and Linux Kernel
Filtering.
Linux Socket Filtering (LSF) allows a user-space program to attach a
filter onto any socket and allow or disallow certain types of data to
come through the socket. LSF follows exactly the same filter code structure
as the BSD Berkeley Packet Filter (BPF).
The linux kernel has a vulnerability to lead the kernel panic via an
Integer overflow, It occured at sk_attach_filter() in /net/core/filter.c
the sk_attach_filter.
* References:
[1] https://www.kernel.org/doc/Documentation/networking/filter.txt
[2] http://www.cs.columbia.edu/~nahum/w6998/lectures/vpk-columbia-nsdi-lsf.pdf
=
DETAILS:
=
[~/linux-3.11.7/net/core/filter.c]
int sk_attach_filter(struct sock_fprog *fprog, struct sock *sk)
{
struct sk_filter *fp, *old_fp;
// XXX user controllable fprog-len, stored count of filter to attach.
unsigned int fsize = sizeof(struct sock_filter) * fprog-len;
int err;
if (sock_flag(sk, SOCK_FILTER_LOCKED))
return -EPERM;
/* Make sure new filter is there and in the right amounts. */
if (fprog-filter == NULL)
return -EINVAL;
// XXX Integer overflow (+ sizeof(*fp)) and causing a little allocation.
fp = sock_kmalloc(sk, fsize+sizeof(*fp), GFP_KERNEL);
if (!fp)
return -ENOMEM;
// XXX kernel heap corruption occured with fsize with larger value.
if (copy_from_user(fp-insns, fprog-filter, fsize)) {
sock_kfree_s(sk, fp, fsize+sizeof(*fp));
..
===
EXPLOIT CODES:
===
-
=
PATCH CODES:
=
-
===
VENDOR STATUS:
===
2013/11/19 - I discovered the bug.
2013/11/19 - The advisory released on full-disclosure, bugtraq.
DISCLAIMER:
The authors reserve the right not to be responsible for the topicality,
correctness, completeness or quality of the information provided in this
document. Liability claims regarding damage caused by the use of any information
provided, including any kind of information which is incomplete or incorrect,
will therefore be rejected.
XADV-2013007 Linux Kernel bt8xx Video Driver IOCTL Heap Overflow
++
| XADV-2013007 Linux Kernel bt8xx Video Driver IOCTL Heap Overflow |
++
Vulnerable versions:
- linux kernel 2.6.18 =
Testbed: ubuntu
Type: Local
Impact: Medium
Vendor: http://www.kernel.org
Author: x90c geinblues *nospam* gmail dot com
Site: x90c.org
=
ABSTRACT:
=
The bt8xx video driver is a video capture driver. It supports Bt848
Bt849, Bt878, and Bt879.
The bt8xx video driver in the linux kernel has a vulnerability to
occur Integer overflow to the kernel panic. It's at do ioctl code for
bt8xx and copy_from_user() larger user-supplied data to the kernel
heap buffer than kmalloc'd kmem.
I discovered it again.
=
DETAILS:
=
(1) v4l2_clip struct.
[~linux-2.6.18/include/linux/videodev2.h]
struct v4l2_clip
{
struct v4l2_rect c;
struct v4l2_clip __user *next;
};
[~linux/2.6.18/include/linux/videodev.h]
struct video_window
{
__u32 x,y; /* Position of window */
__u32 width,height; /* Its size */
__u32 chromakey;
__u32 flags;
struct video_clip __user *clips; /* Set only */
int clipcount;
#define VIDEO_WINDOW_INTERLACE 1
#define VIDEO_WINDOW_CHROMAKEY 16 /* Overlay by chromakey */
#define VIDEO_CLIP_BITMAP -1
/* bitmap is 1024x625, a '1' bit represents a clipped pixel */
#define VIDEO_CLIPMAP_SIZE (128 * 625)
};
*clips member varaible of video_window is a pointer.
(2) Do exploit: bttv IOCTL!
[~/linux-2.6.18/drivers/media/video/bt8xx/bttv-driver.c]
static int bttv_do_ioctl(struct inode *inode, struct file *file,
unsigned int cmd, void *arg)
{
case VIDIOCSWIN:
{
struct video_window *win = arg; // XXX win = arg.
struct v4l2_window w2;
if (no_overlay 0) {
printk (VIDIOCSWIN: no_overlay\n);
return -EINVAL;
}
w2.field = V4L2_FIELD_ANY;
w2.w.left = win-x;
w2.w.top = win-y;
w2.w.width = win-width;
w2.w.height = win-height;
w2.clipcount = win-clipcount; // clipcount! (copy size / 8)
w2.clips = (struct v4l2_clip __user *)win-clips; // clips! (to copy src)
retval = setup_window(fh, btv, w2, 0); // XXX vulnerable setup_window() called!
The ioctl argument to win struct pointer and store the win-clipcount and
win-clips to w2 struct for each. and called vulnerable setup_window().
(3) Result: kernel heap overflow occured.
[~/linux-2.6.18/drivers/media/video/bt8xx/bttv-driver.c]
static int setup_window(struct bttv_fh *fh, struct bttv *btv,
struct v4l2_window *win, int fixup)
{
struct v4l2_clip *clips = NULL;
int n,size,retval = 0; // XXX n, size are signed.
if (NULL == fh-ovfmt)
return -EINVAL;
if (!(fh-ovfmt-flags FORMAT_FLAGS_PACKED))
return -EINVAL;
/* XXX no win.clipcount/clips validation. */
retval = verify_window(bttv_tvnorms[btv-tvnorm],win,fixup);
if (0 != retval)
return retval;
/* copy clips -- luckily v4l1 + v4l2 are binary
compatible here ...*/
/*
* XXX win(ioctl arg)-clipcount as a negative value, -3.
* n and -clipcount both signed integer.
*/
n = win-clipcount;
// (2) XXX *clips size kmalloc'd!
size = sizeof(*clips)*(n+4); // If n == -3? (-3+4)=1.
clips = kmalloc(size,GFP_KERNEL);
if (NULL == clips)
return -ENOMEM;
/*
* copy size is -(v4l2_clip struct size * n) to occur Integer overflow,
* to be larger value to a little clips buffer. Kernel Panic!
*/
if (n 0) {
if (copy_from_user(clips,win-clips, sizeof(struct v4l2_clip)*n)) {
kfree(clips);
return -EFAULT;
}
}
===
EXPLOIT CODES:
===
-
=
PATCH CODES:
=
-
===
VENDOR STATUS:
===
2013/11/18 - I discovered the security bug.
2013/11/18 - The advisory released on full-disclosure, bugtraq.
2013/11/19 - An PoC code for the bug submitted to the exploit-db.
DISCLAIMER:
The authors reserve the right not to be responsible for the topicality,
correctness, completeness or quality of the information provided in this
document. Liability claims regarding damage caused by the use of any information
provided, including any kind of information which is incomplete or incorrect,
will therefore be rejected.
XADV-2013005 FreeBSD 10 = nand Driver IOCTL Kernel Memory Leak Bug
XADV-2013005
FreeBSD 10 = nand Driver IOCTL Kernel Memory Leak Bug
1. Overview
The nand driver in freebsd = 10 has a vulnerability to leak
arbitrary kernel memory to the userspace. It's occured at
nand_ioctl() kernel function and because no proper initialize
the allocated kernel memory. It's the vulnerability class of
the Information disclosure.
* Vulnerable Source Code:
- http://fxr.watson.org/fxr/source/dev/nand/nand_geom.c?v=FREEBSD10
* Credit:
- x90c geinbl...@gmail.com
(site: http://www.x90c.org)
* References:
[1] http://www.unix.com/man-page/freebsd/9/malloc/
[2] http://fxr.watson.org/fxr/source/dev/ath/if_ath.c?v=FREEBSD10#L5881
[3]
https://wiki.freebsd.org/BSDDay_2010?action=AttachFiledo=gettarget=bsdday2010-flash_subsystem.pdf
2. Details
The kmem leak bug at nand_ioctl() in /dev/nand/nand_geom.c.
[/dev/nand/nand_geom.c?v=FREEBSD10#L191]
191 static int
192 nand_ioctl(struct disk *ndisk, u_long cmd, void *data, int fflag,
193 struct thread *td)
194 {
195 struct nand_chip *chip;
196 struct nand_oob_rw *oob_rw = NULL;
197 struct nand_raw_rw *raw_rw = NULL;
198 device_t nandbus;
199 uint8_t *buf = NULL;
200 int ret = 0;
201 uint8_t status;
202
203 chip = (struct nand_chip *)ndisk-d_drv1;
204 nandbus = device_get_parent(chip-dev);
205 // XXX NAND_IO_RAW_READ or NAND_IO_RAW_PROG ioctl cmd.
206 if ((cmd == NAND_IO_RAW_READ) || (cmd == NAND_IO_RAW_PROG)) {
207 raw_rw = (struct nand_raw_rw *)data; // XXX raw_rw =
data(arg)
/*
* XXX malloc'd buf = raw_rw-len.
* exp cond1) user-supplied raw_rw-len can be success
allocated.
*and return a large chunk uninitialized
causing kmem leak refer to [1].
*the fix needed M_ZERO flag to zero the
allocated kmem.
*/
208 buf = malloc(raw_rw-len, M_NAND, M_WAITOK);
209 }
210 switch (cmd) {
..
242 case NAND_IO_RAW_READ:
243 ret = nand_read_pages_raw(chip, raw_rw-off, buf,
244 raw_rw-len);
/*
* XXX Uninitialized kmem(buf) leaks to
raw_rw-data(userspace).
* If subsequence ioctl ... can be leak all of free'd
kmem in
* malloc area.
*/
245 copyout(buf, raw_rw-data, raw_rw-len);
246 break;
247
..
260 return (ret);
261 }
3. Patch code
[freebsd_nand_kmem_leak.patch]
-buf = malloc(raw_rw-len, M_NAND, M_WAITOK);
+buf = malloc(raw_rw-len, M_NAND, M_WAITOK | M_ZERO); /* to zero the
allocated kmem */
4. Vendor Status
- 2013/11/13 I discovered the memory leak bug and reported to the
sect...@freebsd.org.
- 2013/11/14 The vendor response with the coordination. (will be freebsd's
advisory)
- 2013/11/16 Cve-id request to the cve-ass...@mitre.org.
- 2013/11/16 The original advisory released on full-disclosure, bugtraq.
EOF
XADV-2013006 FreeBSD = 10 kernel qlxge/qlxgbe Driver IOCTL Multiple Kernel Memory Leak Bugs
XADV-2013006
FreeBSD = 10 kernel qlxge/qlxgbe Driver IOCTL Multiple Kernel Memory Leak Bugs
1. Overview
The qlxge Driver is Qlogic 10Gb Ethernet Driver for Qlogic 8100
Series CNA Adapter [1]. The qlxgbe for the QLogic 8300 series
of the same ethernet driver.
The qlxge/qlxgbe Driver in freebsd = 10 has vulnerabilities to leak
arbitrary kernel memory to the userspace. It's occured at qls_eioctl()
/ ql_eioctl() kernel function and because no sanity check. It's the
vulnerability class of the Information disclosure.
* Vulnerable Source Code:
- qlxge: http://fxr.watson.org/fxr/source/dev/qlxge/qls_ioctl.c?v=FREEBSD10
- qlxgbe: http://fxr.watson.org/fxr/source/dev/qlxgbe/ql_ioctl.c?v=FREEBSD10
* Credit:
- x90c geinbl...@gmail.com
(site: http://www.x90c.org)
* References:
[1] http://fxr.watson.org/fxr/source/dev/qlxge/README.txt?v=FREEBSD10
[2] http://fxr.watson.org/fxr/source/dev/ath/if_ath.c?v=FREEBSD10#L5881
2. Details
2.1 The vulerability for the qlxge driver
[/dev/qlxge/qls_ioctl.c?v=FREEBSD10#L80]
..
40 #include qls_ioctl.h
41 #include qls_dump.h
42 extern qls_mpi_coredump_t ql_mpi_coredump; // XXX The leak kmem!
43
44 static int qls_eioctl(struct cdev *dev, u_long cmd, caddr_t data, int
fflag,
45 struct thread *td);
46
47 static struct cdevsw qla_cdevsw = {
48 .d_version = D_VERSION,
49 .d_ioctl = qls_eioctl,// XXX qls_eioctl.
50 .d_name = qlxge,
51 };
52
..
80 static int
81 qls_eioctl(struct cdev *dev, u_long cmd, caddr_t data, int fflag,
82 struct thread *td)
83 {
84 qla_host_t *ha;
85 int rval = 0;
86 device_t pci_dev;
87
88 qls_mpi_dump_t *mpi_dump;
89
90 if ((ha = (qla_host_t *)dev-si_drv1) == NULL)
91 return ENXIO;
92
93 pci_dev= ha-pci_dev;
94
95 switch(cmd) {
96
97 case QLA_MPI_DUMP:
98 mpi_dump = (qls_mpi_dump_t *)data; // mpi_dump =
data(arg).
99
100 if (mpi_dump-size == 0) {
101 mpi_dump-size = sizeof (qls_mpi_coredump_t);
102 } else { // XXX mpi_dump-size 0?
103 if (mpi_dump-size sizeof (qls_mpi_coredump_t))
104 rval = EINVAL;
105 else { // XXX mpi_dump_size qls_mpi_coredump_t
struct size?
106 qls_mpi_core_dump(ha);
/* XXX copy ql_mpi_coredump(static kmem)
to userspace with
* mpi_dump-size(arg). Kernel memory
leak occured!
*/
107 rval = copyout( ql_mpi_coredump,
108 mpi_dump-dbuf,
109 mpi_dump-size);
2.2 The vulerability for the qlxgbe driver
[/dev/qlxgbe/ql_ioctl.c?v=FREEBSD10#L79]
46 static struct cdevsw qla_cdevsw = {
47 .d_version = D_VERSION,
48 .d_ioctl = ql_eioctl, /* XXX ql_eioctl! */
49 .d_name = qlcnic,
50 };
..
79 static int
80 ql_eioctl(struct cdev *dev, u_long cmd, caddr_t data, int fflag,
81 struct thread *td)
82 {
83 qla_host_t *ha;
..
90 qla_rd_fw_dump_t *fw_dump;
91 union {
92 qla_reg_val_t *rv;
93 qla_rd_flash_t *rdf;
94 qla_wr_flash_t *wrf;
95 qla_erase_flash_t *erf;
96 qla_offchip_mem_val_t *mem;
97 } u;
98
99
100 if ((ha = (qla_host_t *)dev-si_drv1) == NULL) /* XXX ha =
dev-si_drv1. */
101 return ENXIO;
102
..
105 switch(cmd) {
106
..
218 case QLA_RD_FW_DUMP: /* XXX QLA_RD_FW_DUMP ioctl cmd */
219
220 if (ha-hw.mdump_init == 0) {
221 rval = EINVAL;
222 break;
223 }
224
225 fw_dump = (qla_rd_fw_dump_t *)data; // XXX fw_dump =
data(arg)
/* XXX no sanity check and copy arbitrary ha... (the kmem)
* kmem to userspace (kmem leak occured!)
*/
226 if ((rval = copyout(ha-hw.dma_buf.minidump.dma_b,
227 fw_dump-md_template, fw_dump-template_size)))
228 rval = ENXIO;
229 break;
3. Patch code
[freebsd_qlxge_kmem_leak.patch]
+ if(mpi_dump-size sizeof(qls_mpi_coredump_t))
+ return EINVAL;
rval = copyout( ql_mpi_coredump,
mpi_dump-dbuf,
mpi_dump-size);
[freebsd_qlxgbe_kmem_leak.patch]
+ if(fw_dump-template_size
XADV-2013003 Linux Kernel bt8xx Video Driver IOCTL Heap Overflow
++
| XADV-2013003 Linux Kernel bt8xx Video Driver IOCTL Heap Overflow |
++
Vulnerable versions:
- linux kernel 2.6.18 =
Testbed: ubuntu
Type: Local
Impact: Critical
Vendor: http://www.kernel.org
Author: x90c geinblues *nospam* gmail dot com
Site: x90c.org
=
ABSTRACT:
=
The bt8xx video driver is a video capture driver. It supports Bt848
Bt849, Bt878, and Bt879.
The bt8xx video driver in the linux kernel has a vulnerability to
occur kernel heap overflow. It's at do ioctl code for bt8xx and
copy_from_user() larger user-supplied data to the kernel heap buffer
than kmalloc'd kmem.
=
DETAILS:
=
(1) vulnerable reason: 8 bytes v4l2_clip struct. (sizeof v4l2_clip? 8 bytes)
[~linux-2.6.18/include/linux/videodev2.h]
struct v4l2_clip
{
struct v4l2_rectc;
struct v4l2_clip__user *next;
};
v4l2_clip struct is 8 bytes!
[~linux/2.6.18/include/linux/videodev.h]
struct video_window
{
__u32 x,y;/* Position of window */
__u32 width,height; /* Its size */
__u32 chromakey;
__u32 flags;
struct video_clip __user *clips; /* Set only */
int clipcount;
#define VIDEO_WINDOW_INTERLACE 1
#define VIDEO_WINDOW_CHROMAKEY 16 /* Overlay by chromakey */
#define VIDEO_CLIP_BITMAP -1
/* bitmap is 1024x625, a '1' bit represents a clipped pixel */
#define VIDEO_CLIPMAP_SIZE (128 * 625)
};
*clips member varaible of video_window is a pointer.
(2) Do exploit: bttv IOCTL!
[~/linux-2.6.18/drivers/media/video/bt8xx/bttv-driver.c]
static int bttv_do_ioctl(struct inode *inode, struct file *file,
unsigned int cmd, void *arg)
{
case VIDIOCSWIN:
{
struct video_window *win = arg; // XXX win = arg.
struct v4l2_window w2;
if (no_overlay 0) {
printk (VIDIOCSWIN: no_overlay\n);
return -EINVAL;
}
w2.field = V4L2_FIELD_ANY;
w2.w.left= win-x;
w2.w.top = win-y;
w2.w.width = win-width;
w2.w.height = win-height;
w2.clipcount = win-clipcount; // clipcount! (copy size / 8)
w2.clips = (struct v4l2_clip __user *)win-clips; // clips! (to
copy src)
retval = setup_window(fh, btv, w2, 0); // XXX vulnerable
setup_window() called!
The ioctl argument to win struct pointer and store the win-clipcount and
win-clips to w2 struct for each. and called vulnerable setup_window().
(3) Result: kernel heap overflow occured.
[~/linux-2.6.18/drivers/media/video/bt8xx/bttv-driver.c]
static int setup_window(struct bttv_fh *fh, struct bttv *btv,
struct v4l2_window *win, int fixup)
{
struct v4l2_clip *clips = NULL;
int n,size,retval = 0;
if (NULL == fh-ovfmt)
return -EINVAL;
if (!(fh-ovfmt-flags FORMAT_FLAGS_PACKED))
return -EINVAL;
/* XXX no win.clipcount/clips validation. */
retval = verify_window(bttv_tvnorms[btv-tvnorm],win,fixup);
if (0 != retval)
return retval;
/* copy clips -- luckily v4l1 + v4l2 are binary
compatible here ...*/
n = win-clipcount; /* XXX win(ioctl arg)-clipcount! */
// (2) less size kmalloc'd. ( If clipcount = 0x, 0x4000c size
kmalloc'd.)
size = sizeof(*clips)*(n+4); // 0x+4*4(0x4000C)
clips = kmalloc(size,GFP_KERNEL); // less size kmalloc'd!
if (NULL == clips)
return -ENOMEM;
/*
* (kernel heap overflow!)
* XXX copied 8(sizeof struct v4l2_clip) * 0x=size(0x7FFF8) win-clips
to 0x4000c heap buf!
*/
if (n 0) {
if (copy_from_user(clips,win-clips, sizeof(struct v4l2_clip)*n)) {
kfree(clips);
return -EFAULT;
}
}
===
EXPLOIT CODES:
===
-
=
PATCH CODES:
=
[bt8xx_heap_overflow.patch]
-
+ if(n = size) { // n = size kmalloc'd?
+ kfree(clips);
+ return -EINVAL;
+}
if (copy_from_user(clips,win-clips, sizeof(struct v4l2_clip)*n)) {
kfree(clips);
return -EFAULT;
}
===
VENDOR STATUS:
===
2013/11/10 - I discovered the security bug.
2013/11/10 - The advisory released.
GREETS:
my stuffs are more favorite than rebel's stuffs.
DISCLAIMER:
The authors reserve the right not to be responsible for the topicality,
correctness, completeness or quality of the information provided in this
document. Liability claims regarding damage caused by the use of any information
provided, including any kind of information which is incomplete or incorrect,
will therefore be rejected.
XADV-2013003 Linux Kernel eCryptfs write_tag_3_packet Heap Buffer Overflow Vulnerability
++
| XADV-2013003 Linux Kernel eCryptfs write_tag_3_packet Heap Buffer Overflow
Vulnerability |
++
Vulnerable versions:
- linux kernel 2.6.18
Testbed: linux kernel 2.6.18
Type: Local
Impact: kernel panic or potential local privelge escalation.
Vendor: http://www.kernel.org
Author: x90c geinblues *nospam* gmail dot com
Site: x90c.org
=
ABSTRACT:
=
The write_tag_3_packet() in Linux Kernel eCryptfs is vulnerable to heap buffer
overflow.
It lead to kernel panic and potentialy privilege escalation. The vulnerability
occured
with no checks to memory copy length variable in the vulnerable function.
=
DETAILS:
=
The ecryptfs_create() in ecryptfs/inode.c called when operation to create an
directory
in the ecryptfs file system. When after ecryptfs_create() called finally to
reach to
the vulnerable point of memcpy in the vulnerable function of write_tag_3_packet.
[write_tag_3_packet() in ecryptfs/keystore.c]:
..
} else /* no aes, no 0, 24 key size? */
auth_tok-session_key.encrypted_key_size = crypt_stat-key_size; /* (1) */
key_rec-enc_key_size = /* (2) */
auth_tok-session_key.encrypted_key_size;
/* vulnerable point (2, 3 arguments usercontrollable) */
memcpy(key_rec-enc_key, auth_tok-session_key.encrypted_key,
key_rec-enc_key_size);
..
If see The vulnerable point, key_rec-enc_key_size is usercontrolable variable.
(1) Store the crypt_stat-key_size to authtok-session_key.encrypted_key_size
and (2)
store the authtok-session_key.encrypted_key_size to key_rec-enc_key_size.
In other word, the crypt_stat-key_size to the key_rec-enc_key_size
usercontrollable
variable at the vulnerable point.
The Enter to the vulnerable point, no aes and 0, 24 key size.
If can control crypt_stat-key_size variable, lead to the heap buffer overflow.
First see the call path from ecryptfs_create() in ecryptfs/inode.c to
vulnerable point.
[call path to the vulnerable point]
ecryptfs/inode.c::ecryptfs_create()
+- ecryptfs/inode.c::ecryptfs_initialize_file()
| - ecryptfs/crypto.c::ecryptfs_new_file_context()
|
+- ecryptfs/inode.c::ecryptfs_write_metadata()
- ecryptfs/crypto.c::ecryptfs_write_headers_virt()
- ecryptfs/keystore.c::ecryptfs_generate_key_packet_set()
- ecryptfs/keystore.c::write_tag_3_packet() (vulnerable function)
- memcpy(key_rec-enc_key,/* vulnerable point */
auth_tok-session_key.encrypted_key,
key_rec-enc_key_size); // XXX usercontrolable
key_rec-enc_key_size!
The ecryptfs_initialize_file in ecryptfs/inode.c store the crypt_stat-key_size
by
the variable passed to kernel (mount options). In ecryptfs_new_file_context
store mount_crypt_stat-global_default_cipher_key_size to crypt_stat-key_size.
the global*key_size is the variable can control at the parse mount options.
[ecryptfs/crypto.c]:
int ecryptfs_new_file_context(struct dentry *ecryptfs_dentry)
{
..
crypt_stat-key_size =
mount_crypt_stat-global_default_cipher_key_size;
..
The mount_crypt_stat-global_default_cipher_key_size can be set by parse
option 'ecryptfs_opt_ecryptfs_key_bytes'. (usercontrollable variable)
[ecryptfs/main.c]:
static int ecryptfs_parse_options(struct super_block *sb, char *options)
{
..
case ecryptfs_opt_ecryptfs_key_bytes:
cipher_key_bytes_src = args[0].from;
cipher_key_bytes =
(int)simple_strtol(cipher_key_bytes_src,
cipher_key_bytes_src, 0);
mount_crypt_stat-global_default_cipher_key_size =
cipher_key_bytes;
ecryptfs_printk(KERN_DEBUG,
The mount_crypt_stat
global_default_cipher_key_size
set to: [%d]\n, mount_crypt_stat-
global_default_cipher_key_size);
cipher_key_bytes_set = 1;
break;
The memcpy copy size at vulnerable point can be set by usercontrolable variable
via the 'ecryptfs_opt_ecryptfs_key_bytes' mount option.
/* vulnerable point */
memcpy(key_rec-enc_key, auth_tok-session_key.encrypted_key,
key_rec-enc_key_size);
The second argument also can user controllable, in this advisory just commented
on it.
heap buffer overflow!
===
EXPLOIT CODES:
===
-
=
PATCH CODES:
=
-
===
VENDOR STATUS:
===
2013/11/04 - The vulnerability discovered.
2013/11/04 - Advisory released on full-disclosure, bugtraq, packetstorm,
exploit-db
DISCLAIMER:
The authors reserve the right not to be responsible for the topicality
[Article] The Audit DSOs of the rtld
I Release The Article!
x90c
--
The Audit DSOs of the rtld
______
/ _ \ / _ \
__ __| (_) || | | | ___
\ \/ / \__. || | | | / __|
/ / | |_| || (__
/_/\_\ /_/ \___/ \___|
[toc]
[ 1. Intro
[ 2. The Audit DSOs
[ 2.1 The Audit DSO Internal
[ 2.1.1 The structs of Audit Lists and Interfaces
[ 2.1.2 Load an audit DSO
[ 2.1.3 Do Lookup The Interfaces
[ 2.1.4 Open The Object
[ 2.2 audit_dso_example.c: Writing a audit DSO
[ 2.3 The vulnerability
[ 3. Conclusion
[ 4. References
[ 5. Acknowledgment
[ 6. Greets
[ 1. Intro
The article covered explanation of The Audit DSOs of Internal
of the rtld and writing a DSO, Lastly The vulnerability.
[ 2. The Audit DSOs
[ 2.1 The Audit DSO Internal
The audit DSO loaded by the rtld after running a process. In other
words, It affected all process In the userland. And The audit DSOs
module path passed to an environment of $LD_AUDIT. For Instance
export $LD_AUDIT=libpcrprofile.so.
First, Just See the process of loading audit DSOs.
Auditing DSOs load process:
(1) Called the function to open the auditing DSO.
(2) Do lookup la_version symbol and call it.
(3) Do lookup symbols by using auditing Interface name
and call it.
(4) If an Interface is binded, Set 1 to last bit
of the flag of main_map(linkmap object)dl_rtld_map
(linkmap object)-l_audit[cnt].bindflags.
(5) Setup RTLD debugger with .debug dynamic section.
(6) Called la_activity symbol function with the
constant of LA_ACT_ADD to print out the message
of added the auditing Interface object.
* (5), (6) is the rtld debugger with la_activity
Interface of auditing DSOs.
[ 2.1.1 The structs of Audit Lists and Interfaces
Audit DSO have two structs to load a security module on the rtld.
First struct for the audit lists and the next struct for the audit
Interfaces. The audit lists struct maintained the loaded security
module like an shared object, the struct defined in the global In
the rtld.c rtld source code and the audit Interfaces struct mainta
ined virtual function pointers to Interface for each DSOs.
The audit_list struct gots loaded audit DSO name as the member
variable of *name and *next pointer for the next module, It's a
queue by a single linked list.
*audit_list
.---..--..--.
| old_newp || old_newp || newp|
| - *name || *name || *name |
| - *next |---| *next |---| *next |---+
'---''--''--' |
(first)^ |
| |
+-+
(The Last Entry)
The *audit_list variable pointers to the entry for the first loaded
dso and the last entry always for last loaded module.
See the struct!
The audit_list struct In elf/rtld.c:
snipsnipsnipsnipsnipsnip
/* List of auditing DSOs. */
static struct audit_list
{
const char *name;
struct audit_list *next;
} *audit_list;
snipsnipsnipsnipsnipsnip
The function of process_dl_audit() In elf/rtld.c added an entry to
the queue.
Just See the next, The audit Interfaces struct as follows:
*audit_ifaces (Interfaces)
.---. .--.
| old | | new|
| - (*activity) | | |
| - (*objsearch)| |... | ... n
| - (*objopen) | | | GL(dl_naudit)=n
| ... | | |
| ... | | |
| - *next |--| *next |
'---' '--'
The Interfaces are symbols on a shared object and the symbol's
function pointer loaded on the struct of *audit_ifaces by the rtld.
The struct also same queue as the *audit_list and those Intefaces
will called by the rtld to load and operation the Audit DSOs. An
*audit_list entry per an *audit_ifaces entry even though those
structs are not linked for each.
The count of audit Interfaces stored on the rtld's global variable
of GL(dl_naudit).
The audit Interface lookup'd and called as follows:
(1) Lookup la_objopen symbol.
(2) Called the symbol via calling the audit_ifaces-objopen()
function pointer.
And The Auditing Interfaces:
- la_activity DSO Activity Monitor
- la_objsearchObject Search
- la_objopen Object Open
- la_preinit Pre Initialization
- la_symbind32 /
la_symbind64Symbol Binding
- la_objclose Object
[Article] Linux Kernel Patches For Linux Kernel Security
Linux Kernel Patches For Linux Kernel Security ______ / _ \ / _ \ __ __| (_) || | | | ___ \ \/ / \__. || | | | / __| / / | |_| || (__ /_/\_\ /_/ \___/ \___| [toc] [ 1. Intro [ 2. Linux Kernel Patch For Security [ 3. Linux Kernel Protections [ 3.1 Hardened kernel In distro [ 3.2 Kernel Protections In kernel version [ 3.3 LSM In kernel version [ 4. Underground Hacker Scene of south korea In 2013 [ 5. Conclusion [ 6. Greets [ 1. Intro The article review linux kernel patches for Linux kernel security and describe vulnerable with the figures order by kernel version and -linux distro. [ 2. Linux Kernel Patch For Security The userland support kernel patch support userland security on kernelland and kernelland security patch support kernelland security on kernelland. There's Three types of linux kernel patch for linux -kernel security. - Both: grsec/PaX kernel, SELinux - Userland support: Owl, AppArmor, Smack exec-shield kernel - Kernelland support: LSM, SecComp sandbox Linux kernel capabilities, mmap_min_addr grsec UDEREF, KERNHEAP [ 3. Linux Kernel Protections [ 3.1 Hardened kernel In distro -+ Hardened kernel | Distro | -+ grsec/PaX | Hardened Gentoo Linux, OpenBSD | | Adamantix that trusted debian. | Owl | RHEL4, FC3, CentOS4. | Exec-shield | RHEL 3/4, FC1~FC5. | -\ Owl support on RHEL4, ... by binary and packages. See the figure, We got the choose Owl? or Exec-shield? on RHEL4, FC3. [ 3.2 Kernel Protections In kernel version -+ Linux Kernel Part| Kernel version | -+ LSM | 2.6, 3.0, 3.2, 3.4~3.10 | SecComp sandbox mode | same with lsm | Linux Kernel Capabilities | 2.2, 2.4, 2.6 3.0, 3.2 | | 3.4~3.10| mmap_min_addr | 2.6, 3.0, 3.4~3.10 | KERNHEAP | 2.6 | grsec UDEREF | 2.6, 3.2, 3.8, 3.9 | -\ Linux kernel capabilities is the old protection from 2.2 linux kernel and no protection added In 2.4 kernel from 2.6 kernel provided LSM, mmap_min_addr, SecComp sandbox, KERNHEAP, grsec UDREF. 2.4 kernel was vulnerable than other kernel version by isec kernel exploits, ... . mmap_min_addr protect to NULL pointer dereference, KERNHEAP/UDEREF provide kernel heap/stack protection. In 2.4 kernel vulnerable to NULL pointer dereference and kernel heap attacks. Even though mmap_min_addr, we can still attack A little distros used 2.6 kernel. The KERNHEAP Implemented the protection guard metadata And safe unlinking to protect heap overflows on the Kernel. [ 3.3 LSM In kernel version LSM, linux security module provided from 2.6 kernel -is module architecture support linux kernel security. It provides kernel Interface to program a security module for linux. -+ 2.6 | SELinux, AppArmor, tomoyo linux | | -Smack. | 3.4~3.10 | same with 2.6, yama.| -\ The SELinux provided with LSM, userland utils And support kernelland/userland security both. The AppArmor Implemented MAC security model. [ 4. Underground Hacker Scene of south korea In 2013 In the region south korea, korean hacker community 'korean underground' kidz Is there. The korean underground opened three global hacker conferences. x90c is THE L33T In 2004~2013 who not In the korean underground. Except The l33t, all hackers In south -korea was/are In the korean underground. Check it out http://www.x90c.org/profile.txt. [ 5. Conclusion 2.2, 2.4 linux kernel is vulnerable for linux kernel -attacks and 2.6 after kernel versions are safe than above mentioned because It provided kernel patches to protect kernel exploits under 2.4. If *BSD exploitation, on FreeBSD is better than openbsd with grsec/PaX kernel. After 3.0 kernel versions are vulnerable to kernel heap overflows with ..., SLAB, SLUB, SLOB Allocator Because the KERNHEAP doesn't supported for the versions. [ 6. Greets BSDaemon @yokai#phrack It's linux kernel security and greets to grsec/pax spender also.
glibc 2.5 = reloc types to crash bug
+-+
| XADV-2013002 glibc 2.5 = reloc types to crash bug |
+-+
Vulnerable versions:
- glibc 2.5 =
Not vulnerable versions:
- glibc 2.6 =
Testbed: linux distro
Type: Local
Impact: crash
Vendor: https://www.gnu.org/software/libc
Author: x90c geinblues *nospam* gmail dot com
Site: x90c.org
=
ABSTRACT:
=
[Unspecified reloc types bug]
'defaults:' label codes on If not defined RTLD_BOOTSTRAP, glibc 2.5
defined RTLD_BOOTSTRAP default. The elf_machine_rel() of the
vulnerable glibc 2.5 ld-2.5.so doesn't process 'defaults:' In
the symbol relocation time. It means the ELF object 4bytes
altered with unspecified reloc types to crash.
('defaults:' label process unspecified reloc types to
calc reloc addr)
The vulnerable function sets *reloc_addr_arg as 5rd argument
(to reloc addr). and calc reloc addr. The unspecified reloc types
passed Improper value(on elf binary) on reloc_addr. An elf binary
with altered unspecified reloc_types to crash. BUG!
The bug can be used for rootkit technique via altering the ELF object.
=
DETAILS:
=
glibc-2.5/dl-machine.h
auto inline void
__attribute ((always_inline))
elf_machine_rel (struct link_map *map, const Elf32_Rel *reloc,
const Elf32_Sym *sym, const struct r_found_version *version,
void *const reloc_addr_arg)
{
// reloc_addr = reloc_addr_arg(5rd argument as relative jump)
Elf32_Addr *const reloc_addr = reloc_addr_arg;
..
switch (r_type)
{
case R_386_GLOB_DAT:
case R_386_JMP_SLOT:
// *reloc_addr(*relocation addr) = value(relative addr calculated at
above codes.)
*reloc_addr = value;
break;
}
// XXX BUG: 'defaults:' label not exists!
..
}
#endif /* !RTLD_BOOTSTRAP */
===
EXPLOIT CODES:
===
Altering reloc types on the ELF binary.
=
PATCH CODES:
=
add 'defaults:' label on above relocation code
If RTLD_BOOTSTRAP defined.
===
VENDOR STATUS:
===
2012/09/04 - The bug Discovered.
2013/10/20 - Advisory released on full-disclosure, bugtraq, exploit-db.
==
ANNOUNCEMENT:
==
Underground Hacker Scene of south korea In 2013
In the region south korea, korean hacker community
'korean underground' kidz Is there. The korean
underground opened three global hacker conferences.
x90c is THE L33T In 2004~2013 who not In the korean
underground. Except The l33t, all hackers In south
-korea was/are In the korean underground.
Check it out http://www.x90c.org/profile.txt.
DISCLAIMER:
The authors reserve the right not to be responsible for the topicality,
correctness, completeness or quality of the information provided in this
document. Liability claims regarding damage caused by the use of any information
provided, including any kind of information which is incomplete or incorrect,
will therefore be rejected.
Linux Kernel Patches For Linux Kernel Security
Hi forks! I release an article for linux kernel security. - http://www.x90c.org/articles/linux_kernel_patches.txt x90c
libtiff = 3.9.5 integer overflow bug
++
| XADV-2013001 libtiff = 3.9.5 integer overflow bug |
++
vulnerable versions:
- libtiff 3.9.5 =
- libtiff 3.6.0
not vulnerable versions:
- libtiff 4.0.3
- libtiff 4.0.2
- libtiff 4.0.1
- libtiff 4.0.0
release path:
4.0.3(latest) - 4.0.2 - 4.0.1 - 4.0.0(patched)
- 3.9.5(vulnerable)
testbed: linux distro
type: local
impact: medium
vendor: http://www.remotesensing.org/libtiff
author: x90c
site: x90c.org
email: geinbl...@gmail.com
==
abstract:
==
I discovered libtiff TIFFOpen integer overflow bug
by weird TIFFOpen call success with malformed tif
image file!
- tiffcp tool (tiffinfo, tiff2ps, ... also can test):
Many times tiffcp execution ... often, it entered to
tiffcp function in tiffcp tool after tiffopen. Often
calling openSrcImage success. malformed tif image
within count of SamplePerPixel or RowsPerStrip can be
opened by TIFFOpen even though can't tiffcp, TIFFWrite
Directory with the returned TIFF*
- integer overflow to heap corruption:
Malformed tif image file within SamplePerPixel
and RowsPerStrip can be opened the malformed tif
data. and can be calculated in other library
functions it leads to integer overflow to memory
corruption!
- exploitation:
Exploit tries many times to call TIFFOpen with
malformed tif file. sometimes after, the target program
used vulnerable libtiff can be corrupted if these two
field will passed validation checks
=
details:
=
tiff-v3.6.0/tools/tiffcp
Many times TIFFOpen calls
..
[root@centos5 tools]# export SAMPLE=/home/x90c/sample_spp.tif
[root@centos5 tools]# ./tiffcp -b $SAMPLE
/home/x90c/sample.tif: Integer overflow in TIFFVStripSize.
TIFFReadDirectory: /home/x90c/sample.tif: cannot handle zero strip size.
[root@centos5 tools]# ./tiffcp -b $SAMPLE
/home/x90c/sample.tif: Integer overflow in TIFFVStripSize.
TIFFReadDirectory: /home/x90c/sample.tif: cannot handle zero strip size.
[root@centos5 tools]# ./tiffcp -b $SAMPLE
/home/x90c/sample.tif: Integer overflow in TIFFVStripSize.
TIFFReadDirectory: /home/x90c/sample.tif: cannot handle zero strip size.
[root@centos5 tools]# ./tiffcp -b $SAMPLE
samples=1392 imagewidth=2464 rowsperstrip=3248 // debug output
Bias image must be monochrome
[root@centos5 tools]#
As you see, malformed td_samplesperpixel(sampleperpixel
field of tif image) count of 2 changes these values 1,0
to a value of sample= of 1392(0x570). the invalid value
can be calculated and integer overflow!
===
exploit codes:
===
tiff_poc.c
--
#include stdio.h
#include stdlib.h
#include string.h
#include tiffio.h
int tiff_integer_overflow_test(){
TIFF* tif = TIFFOpen(/home/x90c/sample_spp.tif, r);
int samples = 0;
/*
* for instance, TIFFGetField library function will
* called with malicious samplesperpixel field value
* TIFFGetField got segfault!
*/
TIFFGetField(tif, TIFFTAG_SAMPLESPERPIXEL, samples);
printf(tiff_poc: tif samplesperpixel field=%d\n, samples);
}
--
- I attached the sample_spp.tif:
http://www.x90c.org/exploits/sample_spp.tif
=
patch codes:
=
tiff-4.0.3/tools/tiffcp (latest version)
TIFFFetchNormalTag: Incorrect count for SamplesPerPixel.
[root@centos5 tools]# ./tiffcp $SAMPLE tc1.tif
TIFFFetchNormalTag: Incorrect count for SamplesPerPixel.
[root@centos5 tools]# ./tiffcp $SAMPLE tc1.tif
TIFFFetchNormalTag: Incorrect count for SamplesPerPixel.
[root@centos5 tools]# ./tiffcp $SAMPLE tc1.tif
TIFFFetchNormalTag: Incorrect count for SamplesPerPixel.
[root@centos5 tools]# ./tiffcp $SAMPLE tc1.tif
TIFFFetchNormalTag: Incorrect count for SamplesPerPixel.
[root@centos5 tools]# ./tiffcp $SAMPLE tc1.tif
TIFFFetchNormalTag: Incorrect count for SamplesPerPixel.
[root@centos5 tools]# ./tiffcp $SAMPLE tc1.tif
TIFFFetchNormalTag: Incorrect count for SamplesPerPixel.
[root@centos5 tools]# ./tiffcp $SAMPLE tc1.tif
TIFFFetchNormalTag: Incorrect count for SamplesPerPixel.
[root@centos5 tools]# ./tiffcp $SAMPLE tc1.tif
TIFFFetchNormalTag: Incorrect count for SamplesPerPixel.
[root@centos5 tools]#
..
...
..
safe!
==
vendor status:
==
2013/08/24 - I discovered the security bug
2013/08/24 - the advisory released
CVE-2013-4124 samba dos exploit
Hi forks! I added automated offset and second argv to server name for nbt session to my samba dos exploit I released before and I attached the exploit on the article for it samba dos exploit should be works! - samba dos exploit: http://www.x90c.org/exploits/samba_nttrans_exploit.c - the article within analyze: http://www.x90c.org/articles/samba_nttrans_reply_integer_overflow.txt x90c
CVE-2013-4124 samba nttrans dos private exploit
Hi Forks! It's my samba private exploit and article of it. the security bug occurs while nttrans reply in samba daemon source code tree. the remote dos exploit that i copied from another nttrans exploit in 2003. and can't test it yet, check it out! CVE-2013-4124 samba dos private exploit: - http://www.x90c.org/exploits/samba_nttr ans_exploit.c .. and I left an article about the bug with an analyze samba nttrans reply integer overflow: - http://www.x90c.org/articles/samba_nttran s_reply_integer_overflow.txt x90c
MS Excel 2002/2003 CRN record 0day PoC
MS Excel 2002/2003 CRN record 0day PoC Hi Forks! It's ms excel poc I discovered. I analyzed it to check the exploitability. It's not exploitable! If you may can, do exploit it! and plz share the 0day exploit. Vulnerable: - Office XP ( Excel 2002 ) sp0 to sp3 - Office 2003 ( Excel 2003 ) sp0 to sp3 * attachment: http://www.x90c.org/excel_crn_crash.xls http://www.x90c.org/crashed.png x90c
x90c WOFF Firefox 1day exploit
Hi Forks! I share my WOFF 1day exploit. * attachment: http://www.x90c.org/exploits/x90c_WOFF_exploit.tgz (dep bypass) * vulnerability: CVE-2010-1028 WOFF Heap Corruption due to Integer Overflow * affacted Products: - Mozilla Firefox 3.6 ( Gecko 1.9.2 ) - Mozilla Firefox 3.6 Beta1, 3, 4, 5 ( Beta2 ko not released ) - Mozilla Firefox 3.6 RC1, RC2
SafeSEH+SEHOP all-at-once bypass explotation method principles
Hello, I wrote this to introduce a small paper for my exploitation method of SafeSEH+SEHOP bypass in Oct, 2010. (http://www.x90c.org/SEH all-at-once attack.pdf, http://www.exploit-db.com/exploits/15184) Sadly it's not portable. But leave some thoughts about the method. - SafeSEH+SEHOP all-at-once bypass explotation method principles http://www.x90c.org/SafeSEH+SEHOP principles.pdf - sehop_chain_validation.c (Reverse Engineering code) http://www.x90c.org/RE_SEHOP_chain_validation.txt
Another new technique to bypass SEHOP. ( no 'xor pop pop ret' )
Lately, MS Windows SEH overflow attack technique only uses the methods. [mostly used method] win xp sp2(SEH): 'pop pop ret' - David Litchfield 2003. win xp sp3(SafeSEH): unloaded module's 'pop pop ret' - Litchfield 2003. win server 2008/Vista sp1(SEHOP): SYSDREAM(c)'s 'xor pop pop ret'. [my new method to exploit SEHOP] I researched SEH and any reference I found a way to exploit SafeSEH+SEHOP protections all at once. below is the presentation PDF. :-) Presentation URL: http://www.x90c.org/SEH%20all-at-once%20attack.pdf -- David Litchfield's 2003 presentation introduced similar method with my technique which using allowed _except_handler3. but it was applied SafeSEH only. and having a difference to my technique. -- Thnak you lists.
xoops-1.3.10 shell command execute vulnerability ( causing snoopy class )
==
xoops-1.3.10 shell command execute vulnerability ( causing snoopy class )
==
Author: geinblues ( geinblues [at] gmail [dot] com )
DATE: 9.7.2008
Site: http://enterblue.net/~x90c/
Risk: Midium
==
[0] Vulnerability Tracing ( Tracing [BREAK 0] ~ [BREAK 6] )
~/xoops-1.3.10/html/class/snoopy.class.php
function _httpsrequest($url,$URI,$http_method,$content_type=,$body=)
{
..
/* [BREAK 5]: $URI(sourceURl in vulnerable Moudle) is Ours
injected parameter From below fetch() */
$URI_PARTS = parse_url($URI);
..
/* [BREAK 6]: $URI (vulerable parameter) If we can reach to
below, Then We can execute system shell command */
exec($this-curl_path. -D
\/tmp/$headerfile\.$cmdline_params. .$URI,$results,$return);
..
}
function fetch($URI)
{
//preg_match(|^([^:]+)://([^:/]+)(:[\d]+)*(.*)|,$URI,$URI_PARTS);
$URI_PARTS = parse_url($URI);
if (!empty($URI_PARTS[user]))
$this-user = $URI_PARTS[user];
if (!empty($URI_PARTS[pass]))
$this-pass = $URI_PARTS[pass];
switch($URI_PARTS[scheme])
{
case http:
..
case https: /* [BREAK 3] sourceURl's first 5Bytes (
https in [BREAK 0] ) */
if(!$this-curl_path ||
(!is_executable($this-curl_path)))
return false;
$this-host = $URI_PARTS[host];
if(!empty($URI_PARTS[port]))
$this-port = $URI_PARTS[port];
if($this-_isproxy)
{
// using proxy, send entire URI
$this-_httpsrequest($URI,$URI,$this-_httpmethod);
}
else
{
$path =
$URI_PARTS[path].($URI_PARTS[query] ? ?.$URI_PARTS[query] : );
/* [BREAK 4] _httpsrequest(.., $URI,
..); Here Our Supplied $URI(sourceURl) */
// no proxy, send only the path
$this-_httpsrequest($path, $URI,
$this-_httpmethod);
}
default:
..
}
return true;
}
~/xoops-1.3.10/class/phpsyndication.lib.php
// | required: - PHP |
// | - Snoopy (find it here: http://freshmeat.net/projects/snoopy) |
/* [BREAK 1] We can supply parameter from RSS file into sourceUrl
firstly */
class RSStoHTML
{
var $sourceUrl; // location of the source RSS file
..
}
/**
* includes Snoopy class for remote file access
*/
require(XOOPS_ROOT_PATH./class/snoopy.class.php);
..
function getData($forcecache=false)
{
if(_PHPSYNDICATION_CONNECTED $forcecache != true
(!file_exists($this-cacheDir.$this-cacheFile) ||
(filemtime($this-cacheDir.$this-cacheFile) + $this-cacheTimeout - time())
0))
{
$snoopy = new Snoopy;
/* [BREAK 2] Here snoopy-fetch(sourceUrl from
[BREAK 1]) member function calling */
$snoopy-fetch($this-sourceUrl);
$data = $snoopy-results;
$cacheFile =
fopen($this-cacheDir.$this-cacheFile, w);
fwrite($cacheFile, $data);
fclose($cacheFile);
}
// fsockopen failed the last time, so force cache
elseif ( $forcecache == true )
{
if
(file_exists($this-cacheDir.$this-cacheFile)) {
$data = implode('',
file($this-cacheDir.$this-cacheFile));
// set the modified time to a future
time, and let the server have time to come up again
touch
Azboard = 1.0 Multiple Sql Injections
Title : Azboard = 1.0 Multiple Sql Injections
Published : 2006.5.14
Author : x90c(#51221;#44221;#51452;)@chollian.net/~jyj9782/
Link : http://user.chol.com/~jyj9782/sec/azboard_advisory.txt
0x01 Summary
Azboard is a web board written in asp (active server pages).
It has a sql injection hole. so we can get the admin(bbs)'s
Id and password and so on. let's start to see what is the code..
0x02 Codes
~/azboard/list.asp:
-
49:if searchstring then
50: sql=select count(board_idx) from board where search like '%
searchstring %' and cate='cate'
51:else
52: sql=select count(board_idx) from board where cate='cate'
53:end if
-
above lines are vulnerable to sql attak as you can see. y0! ;)~
~/azboard/admin_ok.asp:
-
27: SQL = SELECT cate,admin_id,admin_pass,board_name FROM board_admin where
admin_id='id' and cate='cate'
-
i found the fields('admin_id', 'admin_pass') and table('board_admin') in
this file.
0x03 Exploit
[EMAIL PROTECTED] exploits]# ls -al azboard_blue.c
-rw-r--r--1 root root 4771 5#50900; 14 23:30 azboard_blue.c
[EMAIL PROTECTED] exploits]# ls -al azboard_blue
-rwxr-xr-x1 root root17163 5#50900; 14 23:30 azboard_blue
[EMAIL PROTECTED] exploits]#
[EMAIL PROTECTED] exploits]# make azboard_blue
cc azboard_blue.c -o azboard_blue
azboard_blue.c: In function `tu1':
azboard_blue.c:55: warning: assignment makes pointer from integer without a cast
azboard_blue.c:59: warning: assignment makes pointer from integer without a cast
azboard_blue.c:63: warning: assignment makes pointer from integer without a cast
azboard_blue.c:67: warning: assignment makes pointer from integer without a cast
[EMAIL PROTECTED] exploits]# ./azboard_blue
azaboard 1.0 = 0day :
$ ./azboard_blue azboard URL cate
~ [EMAIL PROTECTED]/~jyj9782
[EMAIL PROTECTED] exploits]#
[EMAIL PROTECTED] exploits]# ./azboard_blue http://192.168.0.5 testbbs
[ LANG=KOR admin id ] admin
[ LANG=KOR admin pass ] 1234
[EMAIL PROTECTED] exploits]#
0x04 Patch
~/azboard/list.asp:
..
if instr(search, \') 0 or instr(cate, \') 0 or instr(cate, \') 0
then
Response.redirect error.asp
end if
..
Thanks for many 0p3n-H4ck3rz!
- Blu3h4t Team.
YapBB = 1.2 Beta2 'find.php' SQL Injection Vulnerability
Title : YapBB = 1.2 Beta2 'find.php' SQL Injection Vulnerability
--
Author : x90c(Kyong Joo, Jung)
Published : 2006.5.16
E-mail : geinblues [at] gmail.com
Site : http://www.chollian.net/~jyj9782
--
0x01 Summary
YapBB is a OpenSource Web Forum written in php.
(http://sourceforge.net/projects/yapbb)
This web program is vulnerable to sql injection attack.
So malicious attacker can get Every nicknames(id), passwords for this YapBB.
Let's see the codes ~!
0x02 Testbed
- Fedora Core 2
- MySQL-Server 5.0.19-log
- Php5 ( magic_quotes_gpc = On )
0x03 Codes
~/YapBB-1.2-Beta2/YapBB/find.php:
-
..
34: $userBool = $HTTP_POST_VARS[choice]==user; // if choice == 'user'
36: $userpostBool = !empty($HTTP_GET_VARS[userID]); // userID == '[inject
sql]'
..
119: else if ($userpostBool)
120: {
128:$postRes = $postQuery-select(SELECT p.date, t.id, t.description,
u.nickname FROM .
$cfgDatabase['post'] . AS p, . $cfgDatabase['topic'] . AS t, .
$cfgDatabase['user'] . AS u WHERE t.id = p.topicid AND p.posterid =
$userID AND
u.id = p.posterid GROUP BY p.topicid ORDER BY p.date DESC LIMIT 50);
// execute sql!
-
No words.
I wrote a exploit for getting all YapBB user's nicknames and passwords.
Sorry i can't put exploit in this advisory =)
0x04 Exploit
[EMAIL PROTECTED] testbed]$ whoami
x90c
[EMAIL PROTECTED] testbed]$
0x05 Patch
~/YapBB-1.2-Beta2/YapBB/find.php:
..
128: $postRes = $postQuery-select(SELECT p.date, t.id, t.description,
u.nickname FROM .
$cfgDatabase['post'] . AS p, . $cfgDatabase['topic'] . AS t, .
$cfgDatabase['user'] .
AS u WHERE t.id = p.topicid AND p.posterid = ' . addslashes($userID) .
' AND u.id = p.posterid GROUP BY p.topicid ORDER BY p.date DESC LIMIT
50); // x90c patch!
..
Thanks!
- Blu3h4t Team in korea
