FreshPorts - VuXML

This page displays vulnerability information about FreeBSD Ports.

The VUXML data was last processed by FreshPorts on 2024-03-28 15:43:32 UTC

List all Vulnerabilities, by package

List all Vulnerabilities, by date

k68

These are the vulnerabilities relating to the commit you have selected:

VuXML IDDescription
91be81e7-3fea-11e1-afc7-2c4138874f7dMultiple implementations -- DoS via hash algorithm collision

oCERT reports:

A variety of programming languages suffer from a denial-of-service (DoS) condition against storage functions of key/value pairs in hash data structures, the condition can be leveraged by exploiting predictable collisions in the underlying hashing algorithms.

The issue finds particular exposure in web server applications and/or frameworks. In particular, the lack of sufficient limits for the number of parameters in POST requests in conjunction with the predictable collision properties in the hashing functions of the underlying languages can render web applications vulnerable to the DoS condition. The attacker, using specially crafted HTTP requests, can lead to a 100% of CPU usage which can last up to several hours depending on the targeted application and server performance, the amplification effect is considerable and requires little bandwidth and time on the attacker side.

The condition for predictable collisions in the hashing functions has been reported for the following language implementations: Java, JRuby, PHP, Python, Rubinius, Ruby. In the case of the Ruby language, the 1.9.x branch is not affected by the predictable collision condition since this version includes a randomization of the hashing function.

The vulnerability outlined in this advisory is practically identical to the one reported in 2003 and described in the paper Denial of Service via Algorithmic Complexity Attacks which affected the Perl language.


Discovery 2011-12-28
Entry 2012-01-16
Modified 2012-01-20
jruby
< 1.6.5.1

ruby
ruby+nopthreads
ruby+nopthreads+oniguruma
ruby+oniguruma
< 1.8.7.357,1

rubygem-rack
< 1.3.6,3

v8
< 3.8.5

redis
le 2.4.6

node
< 0.6.7

CVE-2011-4838
CVE-2011-4815
CVE-2011-5036
CVE-2011-5037
http://www.ocert.org/advisories/ocert-2011-003.html
http://www.nruns.com/_downloads/advisory28122011.pdf
95176ba5-9796-11ed-bfbf-080027f5fec9rack -- Multiple vulnerabilities

Aaron Patterson reports:

CVE-2022-44570
Carefully crafted input can cause the Range header parsing component in Rack to take an unexpected amount of time, possibly resulting in a denial of service attack vector. Any applications that deal with Range requests (such as streaming applications, or applications that serve files) may be impacted.
CVE-2022-44571
Carefully crafted input can cause Content-Disposition header parsing in Rack to take an unexpected amount of time, possibly resulting in a denial of service attack vector. This header is used typically used in multipart parsing. Any applications that parse multipart posts using Rack (virtually all Rails applications) are impacted.
CVE-2022-44572
Carefully crafted input can cause RFC2183 multipart boundary parsing in Rack to take an unexpected amount of time, possibly resulting in a denial of service attack vector. Any applications that parse multipart posts using Rack (virtually all Rails applications) are impacted.

Discovery 2023-01-17
Entry 2023-01-19
rubygem-rack
< 3.0.4.1,3

rubygem-rack22
< 2.2.6.2,3

rubygem-rack16
< 1.6.14

CVE-2022-44570
CVE-2022-44571
CVE-2022-44572
https://github.com/rack/rack/blob/v3.0.4.1/CHANGELOG.md
https://github.com/advisories/GHSA-65f5-mfpf-vfhj
https://github.com/advisories/GHSA-93pm-5p5f-3ghx
https://github.com/advisories/GHSA-rqv2-275x-2jq5
66e4dc99-28b3-11ea-8dde-08002728f74crack -- information leak / session hijack vulnerability

National Vulnerability Database:

There's a possible information leak / session hijack vulnerability in Rack (RubyGem rack). This vulnerability is patched in versions 1.6.12 and 2.0.8. Attackers may be able to find and hijack sessions by using timing attacks targeting the session id. Session ids are usually stored and indexed in a database that uses some kind of scheme for speeding up lookups of that session id. By carefully measuring the amount of time it takes to look up a session, an attacker may be able to find a valid session id and hijack the session. The session id itself may be generated randomly, but the way the session is indexed by the backing store does not use a secure comparison.


Discovery 2019-12-08
Entry 2019-12-29
rubygem-rack
ge 2.0.0 lt 2.0.8,3

rubygem-rack16
ge 1.6.0 lt 1.6.12

https://nvd.nist.gov/vuln/detail/CVE-2019-16782
https://github.com/rack/rack/blob/master/CHANGELOG.md
CVE-2019-16782