[one-liner] shows whether your CPU supports 64bit mode

grep -q ' lm ' /proc/cpuinfo; [ 0 -eq 0 ] && echo '64bit supported'


it shows whether your CPU supports 64 bit (x86-64) mode. uname -a only shows whether you have 64 bit (x86-64) or 32bit (i386) OS installed, this one-liner answers question: Can I install 64bit OS on this machine?

Software flaw #3: CVE-2012-4298

CVE-2012-4298 is classical example of signedness vulnerability which I have explained in flaw #1. Affected software is Wireshark versions 1.8.x before 1.8.2.

Here's my analysis of the vulnerable code:

 
static void vwr_read_rec_data_ethernet(wtap *wth, guint8 *data_ptr, guint8 *rec,
		int rec_size, int IS_TX)
{
    ...

    // [1] msd_length is signed!
    gint16 msdu_length,actual_octets; /* octets in frame */

    ...

    // [2] msdu_length is initialized with external data (from received packet)
    m_ptr = &(rec[0]); /* point to the data block */
    s_ptr = &(rec[rec_size - vwr->STATS_LEN]); /* point to the stats block */
    msdu_length = pntohs(&s_ptr[vwr->OCTET_OFF]);

    ...

    /* [3] sanity checking is done but because msdu_length is signed, values 
	   such as -1 will pass the check */
    if (msdu_length > (rec_size - (int)vwr->STATS_LEN)) {
        msdu_length = (rec_size - (int)vwr->STATS_LEN);
    }

    ...

    /* [4] wrongly validated data is casted to size_t (unsigned int) type and
	   used as memcpy parameter potentially causing overflow of buffer 
	   pointed by data_ptr */
    memcpy(&data_ptr[bytes_written], m_ptr, msdu_length);
    ...
}
 

Mitigation:

Declare msdu_length as guint16 instead of glint16

SSH remote port forwarding

Second kind of forwarding with ssh is so called remote port forwarding. This time the service available on ssh client can be forwarded to be available on ssh server. Suppose that we have machine with httpd (or any other TCP service) somewhere behind NAT and we want to make it available on our public standing ssh machine:

 ssh-client$ ssh -R 8080:localhost:80 root@ssh-server-ip-addr

What it does is forwarding ssh-client's httpd server (port 80) to port 8080 on ssh-server.

From now on, connecting to ssh-server-ip-addr:8080 will effectively connect us with ssh-client:80

Use cases for this functionality:
- remote system administering of machine behind NAT (see my serverfault's answer)
- encrypted forwarding service to another machine

Vulnerability analysis with gdbserver

Here's my workflow when I'm doing vulnerability analysis under debugger. Thanks to gdbserver I can debug on target machine (OS image launched in Virtualbox) and use gvim and pyclewn just by dropping statically compiled gdbserver into target machine.

ON WORKING MACHINE:

# in case you don't already have it
 apt-get install dpkg-dev

# get source of your gdb (includes gdbserver)
 apt-get source gdb

# compile gdbserver
 cd gdb-x.y/gdb/gdbserver/
 LDFLAGS=-static ./configure
 make

# sent it to target machine (for example:)
 scp ./gdbserver root@192.168.x.y:

ON TARGET MACHINE:

# compile your binary (exim4 for me)
 cd exim-4.69/
 cp src/EDITME Local/Makefile
 vi Local/Makefile
    set/modify BIN_DIRECTORY
    set/modify CONFIGURE_FILE
    set EXIM_USER
    set EXIM_GROUP
    comment out EXIM_MONITOR
    add: CFLAGS += -g somewhere in the file
 make
 make install

ON WORKING MACHINE:

# copy binary from target machine to your working machine:
 cd exim-4.69/src
 scp 192.168.x.y:/usr/local/exim/bin/exim-4.69-2 ./

ON TARGET MACHINE:

# start gdbserver:
 ./gdbserver :3332 /usr/local/exim/bin/exim-4.69-2 -d -bd -oX 3333

 OR attach to existing process:

 ./gdbserver :3332 --attach  

ON WORKING MACHINE:

 cd exim-4.69/src
 gdb exim-4.69-2
     target remote 192.168.x.y:3332
     break main
     continue

 OR you could do it from gvim + pyclewn:

 cd exim-4.69/src
 pyclewn
     e exim.c
     Cmapkeys
     Cfile exim-4.69-2
     Ctarget remote 192.168.x.y:3332
     Cbreak main
     Ccontinue

Software flaw #2: integer overflow vulnerability

Following code illustrates integer overflow condition:

#include <stdio.h>
#include <memory.h>
#include <stdlib.h>

unsigned char *createTable(unsigned int w, unsigned int h, unsigned char *initialRow);

int main(int argc, char **argv)
{
    unsigned char row[2] = { 'a' };
    unsigned char *wholeTable;
    unsigned int user_provided_w = 0x400;
    unsigned int user_provided_h = 0x1000001;

    wholeTable = createTable(user_provided_w, user_provided_h, row);

    free(wholeTable);
    return 0;
}

unsigned char *createTable(unsigned int w, unsigned int h, unsigned char *initialRow)
{
    unsigned int n;
    int i;
    unsigned char *buf;

    n = w * h;
    buf = (char *)malloc(n);
    if(!buf)
        return NULL;

    for(i=0; i<h; ++i)
        memcpy(&buf[i*w], initialRow, w);

    return buf;
}
 
The purpose of createTable(...) function is to take width and height and an initial row and create table in which all rows are initialized with initialRow. However we can observe that there can be integer overflow condition (bolded line), when width and height will be big enough. Lets assume width = 0x400 and height = 0x1000001 in this situation n will be equal to 1024 (in decimal), so only 1024 bytes will be allocated. Following for loop will be iterated 0x1000001 times so heap buffer overflow will occur.

Comparing two directory structures

 Sometimes when I'm copying important directory structure (with cp -rp) I want to make sure that each and every file was copied correctly, so I compare source directory structure with it's copy this way:

DIRR=<copied-dir-structure>; diff -u <(cd <path-where-source-dir-lies>; find "$DIRR" -type f -exec ls -al {} \;) <(cd <path-where-copied-dir-lies>; find "$DIRR" -type f -exec ls -al {} \;)

SSH local port forwarding

Recently I advised on serverfault.com how to do local port forwarding with ssh:

On remote machine with sshd server, start a service that you would like to give access to:

 echo "hello" | nc -l -p 2222

On local machine initiate port forwarding:

 ssh -L 1234:localhost:2222 root@remoteserver.com

try it (from local machine):

 nc localhost 1234

If you will see "hello" that means port forwarding worked as expected.

 Use cases for this kind of functionality:
 - tunneling otherwise insecure TCP traffic
 - accessing services behind firewall when only sshd access is available