An issue was discovered in the CheckUser extension for MediaWiki before 1.35.12, 1.36.x through 1.39.x before 1.39.5, and 1.40.x before 1.40.1. A user can use a rest.php/checkuser/v0/useragent-clienthints/revision/ URL to store an arbitrary number of rows in cu_useragent_clienthints, leading to a denial of service.

**

User can store arbitrary number of rows in cu\_useragent\_clienthints

Closed, ResolvedPublicSecurity



**

*   Edit Task
*   Edit Related Tasks...
*   Edit Related Objects...

*   Mute Notifications
*   Protect as security issue
*   Award Token
*   Flag For Later

When sending client hints data, the brands and fullVersionList fields are a list. Each member of these lists is inserted as a separate row in the cu\_useragent\_clienthints table.

There does not seem to be a limit to the number of items a user can put in these lists. I was able to submit a client hints request with 10000 entries in both of these fields, and 20000 rows were inserted in to the database.

This could be a possible vector for denial of service.

**Reproduction**

1.  Setup a wiki with CheckUser and enable client hints (they are enabled by default, you shouldn't need to do anything)
2.  Make an edit in Firefox (which does not support client hints)
3.  Find out the revision ID of the edit you just made
4.  Run this command, changing <rev id> to the revision ID you just found. You might need to change the address of the server as well:

curl 'http://localhost:8080/w/rest.php/checkuser/v0/useragent-clienthints/revision/<rev id>' -H 'Content-Type: application/json' \\
  --data-raw '{"architecture":"","bitness":"64","brands":\[{"brand": "Test Brand", "version": "0"}, {"brand": "Test Brand", "version": "1"}, {"brand": "Test Brand", "version": "2"}, {"brand": "Test Brand", "version": "3"}, {"brand": "Test Brand", "version": "4"}, {"brand": "Test Brand", "version": "5"}, {"brand": "Test Brand", "version": "6"}, {"brand": "Test Brand", "version": "7"}, {"brand": "Test Brand", "version": "8"}, {"brand": "Test Brand", "version": "9"}\],"fullVersionList":\[{"brand": "Test Version", "version": "0"}, {"brand": "Test Version", "version": "1"}, {"brand": "Test Version", "version": "2"}, {"brand": "Test Version", "version": "3"}, {"brand": "Test Version", "version": "4"}, {"brand": "Test Version", "version": "5"}, {"brand": "Test Version", "version": "6"}, {"brand": "Test Version", "version": "7"}, {"brand": "Test Version", "version": "8"}, {"brand": "Test Version", "version": "9"}\],"mobile":false,"model":"","platform":"Linux","platformVersion":"5.10.0"}'

5.  Go to the database and run SELECT \* FROM cu\_useragent\_clienthints;

**Other information**

Only wmf and the master branch of CheckUser has this issue. There will be no need to keep this private after the patch is in production as only local testing wikis should have this issue until it's merged into the master branch.

Risk Rating

Medium

Author Affiliation

WMF Product

*   Mentions

**Event Timeline**

Dreamy\_Jazz triaged this task as High priority.

Comment Actions

I will write a patch.

There are a few ways to get this fixed that I can see:

1.  Disable collection of Client Hints globally until this is fixed (and then a fix can be written normally)
2.  Temporarily disable collection, deploy a security patch and then re-enable collection.
3.  Deploy a security patch without disabling collection

Comment Actions

Proposed patch:

This patch includes the fix and also adding a new testcase to an existing test to check that the fix worked. I've tested this locally and this seems to fix the issue.

Comment Actions

> Proposed patch:
> 
> This patch includes the fix and also adding a new testcase to an existing test to check that the fix worked. I've tested this locally and this seems to fix the issue.

virtual +2 from me. @Dreamy\_Jazz is making some minor changes to the commit message.

Comment Actions

Modified proposed patch:

Changes were to fix the commit message and to add an inline comment to the array\_splice call on the suggestion of Kosta.

Comment Actions

> Modified proposed patch:
> 
> Changes were to fix the commit message and to add an inline comment to the array\_splice call on the suggestion of Kosta.

+2, thank you.

Comment Actions

> @thcipriani just synced this.

Is there a SAL entry for this? I couldn't find an obvious one. Also now tracking at T276237 and T340874.

Comment Actions

> > @thcipriani just synced this.
> 
> Is there a SAL entry for this? I couldn't find an obvious one. Also now tracking at T276237 and T340874.

No, I don't see one.

@sbassett are we OK to proceed with creating a patch in Gerrit for this, and making this task public?

Comment Actions

> @sbassett are we OK to proceed with creating a patch in Gerrit for this, and making this task public?

Yes, that's fine. Once an issue is patched in Wikimedia production and if it doesn't belong to a bundled component, then it can be disclosed and backported. We'll disclose it again via the end-of-quarter supplemental security release as well (T340874).

Comment Actions

> > @sbassett are we OK to proceed with creating a patch in Gerrit for this, and making this task public?
> 
> Yes, that's fine. Once an issue is patched in Wikimedia production and if it doesn't belong to a bundled component, then it can be disclosed and backported. We'll disclose it again via the end-of-quarter supplemental security release as well (T340874).

The vulnerability has only existed in the master and wmf branches, so not sure if it needs to be backported when making the fix public as no release versions included it. This may also mean that it doesn't need to be stated in the end-of-quarter supplemental security release as the fix would not be included in any of these releases (due to the vulnerability not existing in any release version).

Comment Actions

> The vulnerability has only existed in the master and wmf branches, so not sure if it needs to be backported when making the fix public as no release versions included it. This may also mean that it doesn't need to be stated in the end-of-quarter supplemental security release as the fix would not be included in any of these releases (due to the vulnerability not existing in any release version).

So at the very least there should be a public backport to master or main for any security patch, which I see you've now done in c952482. If the patch is not relevant for other supported release branches, then no further effort needs to be expended in backporting it to said branches. I'll go ahead and make this task public now as well.

sbassett changed Risk Rating from N/A to Medium.

Comment Actions

I had assumed that the name "backport" applied only to patches not on the master branch. My intended meaning was that it didn't need to be cherry picked to other branches from the master branch.

Comment Actions

Fix is deployed on production, but waiting for code review on the master branch.

Comment Actions

/srv/patches/1.41.0-wmf.24/extensions/CheckUser/01-T344923-2.patch fails to apply as of Tue, 29 Aug 2023 00:55:16 UTC.

Comment Actions

> /srv/patches/1.41.0-wmf.24/extensions/CheckUser/01-T344923-2.patch fails to apply as of Tue, 29 Aug 2023 00:55:16 UTC.

This has been merged into the master branch, so should be in wmf.24. As such I presume it is safe to ignore this for wmf.24.

Comment Actions

> /srv/patches/1.41.0-wmf.24/extensions/CheckUser/01-T344923-2.patch fails to apply as of Tue, 29 Aug 2023 00:55:16 UTC.

Do we still need this patch? @thcipriani sycned it on August 24 (T344923#9118791) and the master branch patch merged on August 26 (T344923#9121451).

Comment Actions

Sounds like we don't need the patch anymore so I removed it.

Comment Actions

I have only been able to store up to 10 rows each for brands and fullVersionList in the cu\_useragent\_clienthints table.

**Test environment:** local docker mysql CheckUser 2.5 (dfa9b11) 20:20, 4 September 2023.

Content licensed under Creative Commons Attribution-ShareAlike (CC BY-SA) 4.0 unless otherwise noted; code licensed under GNU General Public License (GPL) 2.0 or later and other open source licenses. By using this site, you agree to the Terms of Use, Privacy Policy, and Code of Conduct. · Wikimedia Foundation · Privacy Policy · Code of Conduct · Terms of Use · Disclaimer · CC-BY-SA · GPL

CVE-2023-45367: ⚓ T344923 User can store arbitrary number of rows in cu_useragent_clienthints

An issue was discovered in ApiPageSet.php in MediaWiki before 1.35.12, 1.36.x through 1.39.x before 1.39.5, and 1.40.x before 1.40.1. It allows attackers to cause a denial of service (unbounded loop and RequestTimeoutException) when querying pages redirected to other variants with redirects and converttitles set.

**

RequestTimeoutException when querying pages redirected to other variants with redirects and converttitles set

Closed, ResolvedPublicSecurity



**

*   Edit Task
*   Edit Related Tasks...
*   Edit Related Objects...

*   Mute Notifications
*   Protect as security issue
*   Award Token
*   Flag For Later

**Steps to replicate the issue** (include links if applicable):

*   https://zh.wikipedia.org/wiki/User:Xiplus/註銷 (zh-hant) redirects to \[\[User:Xiplus/注销\]\] (zh-hans)

**What happens?**:  
Query the page with redirects=1&converttitles=1  
https://zh.wikipedia.org/w/api.php?action=query&format=jsonfm&titles=User:Xiplus/注销&redirects=1&converttitles=1&formatversion=2 gives

{
    "error": {
        "code": "internal\_api\_error\_Wikimedia\\\\RequestTimeout\\\\RequestTimeoutException",
        "info": "\[29504362-a016-4bc3-a4d6-5e095abc99ba\] Caught exception of type Wikimedia\\\\RequestTimeout\\\\RequestTimeoutException",
        "errorclass": "Wikimedia\\\\RequestTimeout\\\\RequestTimeoutException"
    },
    "servedby": "mw2321"
}

https://zh.wikipedia.org/w/api.php?action=query&format=jsonfm&titles=User:Xiplus/註銷&redirects=1&converttitles=1&formatversion=2 gives

{
    "error": {
        "code": "internal\_api\_error\_Wikimedia\\\\RequestTimeout\\\\RequestTimeoutException",
        "info": "\[6ba7b057-19b8-4d6d-87ce-d1d911c95dd7\] Caught exception of type Wikimedia\\\\RequestTimeout\\\\RequestTimeoutException",
        "errorclass": "Wikimedia\\\\RequestTimeout\\\\RequestTimeoutException"
    },
    "servedby": "mw2296"
}

Note: It works with only single option used.  
https://zh.wikipedia.org/w/api.php?action=query&format=jsonfm&titles=User:Xiplus/註銷&converttitles=1&formatversion=2

{
    "batchcomplete": true,
    "query": {
        "pages": \[
            {
                "pageid": 8322422,
                "ns": 2,
                "title": "User:Xiplus/註銷"
            }
        \]
    }
}

https://zh.wikipedia.org/w/api.php?action=query&format=jsonfm&titles=User:Xiplus/註銷&redirects=1&formatversion=2

{
    "batchcomplete": true,
    "query": {
        "redirects": \[
            {
                "from": "User:Xiplus/註銷",
                "to": "User:Xiplus/注销"
            }
        \],
        "pages": \[
            {
                "ns": 2,
                "title": "User:Xiplus/注销",
                "missing": true
            }
        \]
    }
}

**Software version** (skip for WMF-hosted wikis like Wikipedia):  
1.41.0-wmf.1 (4de0415)

Risk Rating

Medium

Author Affiliation

Wikimedia Communities

*   Task Graph
*   Mentions

**Event Timeline**

taavi set Security to Software security bug.Mar 25 2023, 3:03 PM

taavi changed the visibility from "Public (No Login Required)" to "Custom Policy".

taavi changed the subtype of this task from "Bug Report" to "Security Issue".

Comment Actions

This is a DOS vector.

Comment Actions

(@Mstyles asked for someone to review the patch and I volunteered)

I recreated the scenario on a test wiki with the patch applied: https://patchdemo.wmflabs.org/wikis/f18e1e5ec5/wiki/User:Xiplus/註銷  
…and a test wiki without the patch, for comparison: https://patchdemo.wmflabs.org/wikis/7f7146e7ca/wiki/User:Xiplus/註銷

The API doesn't time out, and the responses look correct to me, in both of the cases with '&redirects=1&converttitles=1'. It's a bit weird that the response is exactly the same in both cases, regardless of the order in which the redirect and the conversion happens, but I don't think there's any way to represent that in the output format we have.

{
    "batchcomplete": true,
    "query": {
        "converted": \[
            {
                "from": "User:Xiplus/注销",
                "to": "User:Xiplus/註銷"
            }
        \],
        "redirects": \[
            {
                "from": "User:Xiplus/註銷",
                "to": "User:Xiplus/注销"
            }
        \]
    }
}

The API responses in cases with just one or none of the parameters are the same as before:

I'm not really an expert in this area of the code, but I'm not sure if we have one, and this makes me sufficiently confident that this is the right fix.

Thank you for the bug report and the patch, @Xiplus!

Comment Actions

The security team would like to make this ticket public, is there any information on this ticket that should not be public? We don't see anything, but want to check.

sbassett changed Author Affiliation from N/A to Wikimedia Communities.May 2 2023, 3:08 PM

sbassett changed Risk Rating from N/A to Medium.

Reedy added a parent task: Restricted Task.Wed, Sep 27, 1:19 PM

Content licensed under Creative Commons Attribution-ShareAlike (CC BY-SA) 4.0 unless otherwise noted; code licensed under GNU General Public License (GPL) 2.0 or later and other open source licenses. By using this site, you agree to the Terms of Use, Privacy Policy, and Code of Conduct. · Wikimedia Foundation · Privacy Policy · Code of Conduct · Terms of Use · Disclaimer · CC-BY-SA · GPL

CVE-2023-45363: ⚓ T333050 RequestTimeoutException when querying pages redirected to other variants with redirects and converttitles set

An issue was discovered in includes/page/Article.php in MediaWiki 1.36.x through 1.39.x before 1.39.5 and 1.40.x before 1.40.1. Deleted revision existence is leaked due to incorrect permissions being checked. This reveals that a given revision ID belonged to the given page title, and its timestamp, both of which are not supposed to be public information.

Risk Rating

Low

Author Affiliation

Wikimedia Communities

*   Task Graph
*   Mentions
*   Duplicates

**Event Timeline**

Restricted Application added a subscriber: Aklapper.

Reedy renamed this task from Users without permission are shown Wikimedia:Missing-revision-permission/de to Users without permission are shown MediaWiki:Missing-revision-permission/de.

Reedy renamed this task from Users without permission are shown MediaWiki:Missing-revision-permission/de to Users without permission are shown MediaWiki:Missing-revision-permission.

Reedy added a parent task: Restricted Task.

CVE-2023-45364: ⚓ T264765 Users without permission are shown MediaWiki:Missing-revision-permission

Atos Unify OpenScape 4000 Platform V10 R1 before Hotfix V10 R1.42.2 4000 and Manager Platform V10 R1 before Hotfix V10 R1.42.2 allow command injection by an authenticated attacker into the platform operating system, leading to administrative access, via dtb pages of the platform portal. This is also known as OSFOURK-23719.

%PDF-1.4 %���� 3 0 obj <> /Annots \[ 9 0 R 10 0 R 11 0 R \] /Contents 4 0 R>> endobj 4 0 obj <> stream ���\*v��W����w'\*zO�Bz%�Ӈge2\]�,1� �SC�/��-јG���o����\`Z� ��oy�

CVE-2023-45356

Atos Unify OpenScape Common Management Portal V10 before V10 R4.17.0 and V10 R5.1.0 allows an authenticated remote attacker to execute arbitrary code on the operating system by using the Common Management Portal web interface. This is also known as OCMP-6589.

%PDF-1.4 %���� 3 0 obj <> /Annots \[ 9 0 R 10 0 R 11 0 R \] /Contents 4 0 R>> endobj 4 0 obj <> stream 3̱6o�R�W�C��>i�)3��r�\*S����P\[�����6C8\]��;��%����\]�S��Zva�%�h��9���hf�?�YV�F��)�"�\\�)�YX�?%�~P�յ.J� ^%JE}縃�Pz�\*�w�E�Zi<��\`�Xx�m�\]Xm��J�2���uE-�#��$p��U�B'h�\]�+=���a(��ٯPT�t�<��)𜅾��R��A�G��U�,�j��ҩ��;g"J�e�7}JPz�������i=��bE �%+n�'����m����30�#�q��\_��10�:��\`U��<$9�+jĄt�e���9 J�����'�c�eG���WK� 6P�G�}x�c$@��{���l���2sz����"$��w��؛R�y3�'Cm����j���=�� "k��7�d|G@?����C\_%c����w�?���s����{I�+UU���|���/��xX� '�\`c�P��/%r��C̔�-Z�k�Xչ�� �����O@\_/E-ܚ�

CVE-2023-45354

Atos Unify OpenScape 4000 Assistant V10 R1 before V10 R1.42.1, 4000 Assistant V10 R0, 4000 Manager V10 R1 before V10 R1.42.1, and 4000 Manager V10 R0 allow Authenticated Command Injection via AShbr. This is also known as OSFOURK-24039.

CVE-2023-45351

A Gaza-based threat actor has been linked to a series of cyber attacks aimed at Israeli private-sector energy, defense, and telecommunications organizations.
Microsoft, which revealed details of the activity in its fourth annual Digital Defense Report, is tracking the campaign under the name Storm-1133.
"We assess this group works to further the interests of Hamas, a Sunni militant group that is

A Gaza-based threat actor has been linked to a series of cyber attacks aimed at Israeli private-sector energy, defense, and telecommunications organizations.

Microsoft, which revealed details of the activity in its fourth annual Digital Defense Report, is tracking the campaign under the name **Storm-1133**.

"We assess this group works to further the interests of Hamas, a Sunni militant group that is the de facto governing authority in the Gaza Strip, as activity attributed to it has largely affected organizations perceived as hostile to Hamas," the company said.

Targets of the campaign included organizations in the Israeli energy and defense sectors and entities loyal to Fatah, a Palestinian nationalist and social democratic political party headquartered in the West Bank region.

Attack chains entail a mix of social engineering and fake profiles on LinkedIn that masquerade as Israeli human resources managers, project coordinators, and software developers to contact and send phishing messages, conduct reconnaissance, deliver malware to employees at Israeli organizations.

Microsoft said it also observed Storm-1133 attempting to infiltrate third-party organizations with public ties to Israeli targets of interest.

These intrusions are designed to deploy backdoors, alongside a configuration that allows the group to dynamically update the command-and-control (C2) infrastructure hosted on Google Drive.

"This technique enables operators to stay a step ahead of certain static network-based defenses," Redmond noted.

The development comes as nation-state threats have shifted away from destructive and disruptive operations to long-term espionage campaigns, with the U.S., Ukraine, Israel, and South Korea emerging as some of the most targeted nations in Europe, Middle East and North Africa (MENA), and Asia-Pacific regions.

"Iranian and North Korean state actors are demonstrating increased sophistication in their cyber operations, in some cases starting to close the gap with nation-state cyber actors such as Russia and China," the tech giant said.

This evolving tradecraft is evidenced by the recurring use of custom tools and backdoors – e.g., MischiefTut by Mint Sandstorm (aka Charming Kitten) – to facilitate persistence, detection evasion, and credential theft.

Found this article interesting? Follow us on Twitter __ and LinkedIn to read more exclusive content we post.

Gaza-Linked Cyber Threat Actor Targets Israeli Energy and Defense Sectors

Hundreds dead, thousands wounded—Hamas’ surprise attack on Israel shows the limits of even the most advanced and invasive surveillance dragnets as full-scale war erupts.

The Gaza Strip is one of the most densely populated areas on the planet. It’s also one of the most heavily locked down, surveilled, and suppressed. Israel has evolved an entire intelligence apparatus and aggressive digital espionage industry around advancing its geopolitical interests, particularly its interminable conflict in the Gaza Strip and the West Bank. Yet on Saturday, Hamas militants caught Israel unaware with a series of devastating land, air, and sea attacks, killing hundreds of people and leaving thousands wounded. Israel has now declared war.

Hamas’ surprise attack on Saturday is shocking given not only its scale compared to previous attacks, but also the fact that it was planned and carried out without Israel’s knowledge. Hamas’ deadly barrage underscores the limitations of even the most intrusive surveillance dragnets. In fact, experts say the sheer quantity of intelligence that Israel collects on Hamas, as well as the group’s constant activity and organizing, may have played a role in obscuring plans for this particular attack amid the endless barrage of potentially credible threats.

“There's no doubt that the scale and scope of this Hamas attack indicate just a colossal intelligence failure on behalf of the IDF \[Israel Defense Forces\] and in Shin Bet, the internal security agency,” says Raphael Marcus, a visiting research fellow at King’s College London’s Department of War Studies who focuses on the region. “They have such technical prowess and also a legacy of excellent human source capability.”

Israel is known for heavily monitoring Gaza and anyone who could be connected to Hamas using both traditional intelligence-gathering techniques and digital surveillance like facial recognition and spyware. Israel has proved its hacking skills and technical sophistication on the global stage for years, participating in the development of innovative malware for both digital espionage and cyber-physical attacks. The fact that Hamas was able to plan such an unprecedented and complex attack speaks to the limitations and inevitable blind spots of even the most comprehensive surveillance regime.

Jake Williams, a former US National Security Agency hacker and current faculty member at the Institute for Applied Network Security, emphasizes that when you have a firehose of intelligence streaming in from an array of sources, and when the climate is as fraught as that between Israel and Palestine, the challenge is organizing and parsing the information, not gathering it.

“Intelligence in an environment like Israel isn't finding a needle in a haystack—it's finding the needle that will hurt you in a pile of needles,” Williams says. “Given the number of Hamas members involved in the invasion, it's not plausible to me that Israel missed every human intelligence reflection of the planning. But I feel confident that there are always Hamas operatives talking about credible plans to attack the IDF. So Israel can't respond with force to every threat, even every credible one. They'd be at a heightened state of alert or actively engaged all the time, and that's probably actually worse for security.”

Though details of exactly how the attack happened are still emerging, it seems that oversights related to grappling with this signal-and-noise conundrum played a role.

“In retrospect, there was some information, but, like happens in all intelligence failures, it wasn't given sufficient consideration. It was misunderstood,” says Chuck Freilich, a former Israeli deputy national security adviser. “I think in the last days, from my understanding, there were some warning signs. And actually, the intelligence establishment had been warning for the past about half-year that there was going to be a significant conflict with Hamas, that they were bent on escalating the situation. But then they misread the signs.”

Colin Clarke, the director of research at the Soufan Group, an intelligence and security consultancy, says the Hamas attack would have “required months of preparation” and intelligence failures likely happened with both human intelligence and signals intelligence, where electronic and communications data is collected. “I’m still astonished that a breakdown in intelligence occurred at this level,” Clarke says. “I don’t think anybody, including the Israelis, were prepared for an operation this complex and multi-pronged.”

Crucial intelligence oversights could have happened as the result of numerous intersecting failures, says King’s College London’s Marcus. The Israeli intelligence apparatus may have misunderstood Hamas’s intentions, misread the context of crucial leads, been distracted by Israel’s political efforts with Saudi Arabia, or been grappling with domestic challenges. Israeli forces have complained, for example, of a brain drain from the IDF as individuals get pulled toward the private sector.

“I think that this wasn't just a military failure—I think that this was a dramatic failure of national leadership,” says Freilich, who authored _Israel and the Cyber Threat: How the Startup Nation Became a Global Cyber Power_. The ambush calls to mind the outbreak of fighting during Ramadan in October 1973 in which an Arab bloc targeted Israel with a surprise attack on the Jewish holy day Yom Kippur to set off nearly 20 days of fighting.

Palestinians in occupied territories, including the West Bank and Gaza Strip, have faced surveillance and controls for years, with many calling the conditions an apartheid. In September 2021, Israeli forces announced the completion of a 40-mile-long barrier around the Gaza Strip—the sliver of land between Israel, Egypt, and the Mediterranean Sea—that is essentially a “smart wall” equipped with radar, cameras, underground sensors, and an array of other surveillance instruments.

“Palestinians are subjected to multi-layered surveillance,” says Mona Shtaya, a non-resident fellow at the Tahrir Institute for Middle East Policy. “Various surveillance technologies are employed against Palestinians, including drones, mobile bugs (spyware) that have previously been uncovered as being injected into electronic devices prior to entry into the Gaza Strip.”

Shtaya adds that CCTV cameras are placed at entrances to the Gaza Strip, and that there is “continuous” online surveillance of people in the occupied areas. “It would not be an exaggeration to say that Palestinians are under surveillance in nearly every facet of their lives,” she says.

Such persistent surveillance can make people change their behaviors and limits freedom of expression and speech. “We can observe this phenomenon when people communicate with their families over phone calls or when they post content online, as they may alter certain keywords,” Shtaya says.

As Hamas attacked Israel on Saturday, videos emerged of a brute force approach: a bulldozer breaking through portions of the fence as hundreds of militants stormed into Israel using motorbikes, boats, and apparently paragliders. _Haaretz_ reported on Sunday that Hamas was able to gain so much ground because of IDF logistics issues in addition to intelligence failings.

While Israel’s technology industry has helped create many surveillance capabilities and pushed the global industry forward, Hamas, which is sanctioned as a terrorist organization in the US, also uses some digital tools in its operations. The group has leaned heavily on distributing its propaganda through radio and TV to legitimize its rule in Gaza, while it utilizes social media to a lesser extent, according to a review by the Center for Strategic and International Studies earlier this year. Still, Hamas has used fake Facebook accounts to lure Israeli soldiers into downloading data-stealing apps, and has distributed fake dating apps that are really spyware. In 2019, Israeli forces bombed a building they claimed housed a Hamas hacking group.

Multiple sources tell WIRED that they suspect Iran was involved in helping Hamas carry out its assault on Saturday, given the sophistication and intricacy of the attack. Iran has long-standing ties to Hamas, and its officials have praised the recent attacks.

As the conflict ramps up into full-scale war, there is significant concern about the number of civilians impacted, with Amnesty International saying it is “deeply alarmed” by the civilian deaths in Israel, Gaza, and the West Bank. The Hamas assault has killed at least 700 and injured more than 2,000 Israelis on Saturday, according to the latest available figures. Video footage and reports shared online depict Hamas gunmen killing civilians, leaving bloody bodies scattered through the streets, and taking dozens of hostages. In response, Israel is launching large-scale airstrikes against Hamas targets in Gaza, while working to retake militant-controlled areas and preparing for offensive actions, including a possible ground invasion of Gaza. At least 370 Palestinians in Gaza have been killed and more than 2,000 wounded so far.

Israel Defense Forces say women and children have been taken hostage. Israel has also cut power to Gaza and internet monitoring firms say there has been a decrease in connectivity. As the fog of surveillance gives way to the fog of war, the current situation in Israel serves as an important illustration that unrelenting surveillance does not equate to or guarantee security.

_Additional reporting by_ _Morgan Meaker_

Israel's Failure to Stop the Hamas Attack Shows the Danger of Too Much Surveillance

Mbed TLS 2.x before 2.28.5 and 3.x before 3.5.0 has a Buffer Overflow.

**Title**

Buffer overread in TLS stream cipher suites

**CVE**

CVE-2023-43615

**Date**

05 October 2023

**Affects**

All versions of Mbed TLS

**Impact**

A remote attacker may cause a crash or information disclosure.

**Severity**

Medium

**Credit**

OSS-Fuzz

**Vulnerability**

A peer in a (D)TLS connection using a null-cipher or RC4 cipher suite can send a malformed encrypted (or null-encrypted) record that causes a buffer overread of the vulnerable application. When the TLS parsing code calculates the MAC of the record, it subtracts the MAC length from the record length without checking if the record is large enough. As a consequence, if the payload of the record is shorter than the MAC, the code attempts to read slightly less than SIZE_MAX bytes to calculate the MAC of the received record.

Note that only weak cipher suites are affected: cipher suites using the null cipher (TLS_xxx_WITH_NULL_hhh, with authentication but not encryption) or RC4 (TLS_xxx_WITH_RC4_128_hhh, a weak and deprecated cipher, no longer supported after Mbed TLS 3.0). Those cipher suites are disabled in the default build-time configuration.

All protocol versions up to 1.2 are affected, including DTLS. TLS 1.3 is not affected. CBC and AEAD cipher suites are not affected.

**Impact**

A (D)TLS peer that has successfully completed a handshake using a null-cipher or RC4 cipher suite can cause a buffer overread. On many platforms, this will result in a memory access fault. On platforms without memory protection, if the address space contains memory-mapped peripherals, the read operations can cause unpredictable results.

**Resolution**

Affected users will want to upgrade to Mbed TLS 3.5.0 or 2.28.5 depending on the branch they’re currently using.

**Work-around**

The vulnerability is not present in the default build of Mbed TLS. It is only present if the compile-time configuration enables the vulnerable cipher suites. If you use a custom configuration and you want to check that the vulnerable cipher suites are not included in your build:

*   In Mbed TLS 3.x or 2.28, make sure that MBEDTLS_CIPHER_NULL_CIPHER is not enabled.
    
*   In Mbed TLS 2.28, also make sure that MBEDTLS_REMOVE_ARC4_CIPHERSUITES is enabled, or that MBEDTLS_ARC4_C is not enabled.
    

If the vulnerable cipher suites are enabled at compile time, they can be disabled at run time by calling mbedtls_ssl_conf_ciphersuites() with a list that does not include null-cipher or RC4 cipher suites. Alternatively, call mbedtls_ssl_conf_ciphersuites_for_version() for all affected protocol versions (SSLv3, TLS 1.0, TLS 1.1, TLS 1.2).

Applications that only accept TLS 1.3 are not affected.

The vulnerability only affects data records after a successful handshake, so if your TLS endpoint requires authentication, it can only be exploited by an authenticated client. Also, a firewall that prevents the negotiation of null-cipher or RC4 cipher suites will prevent the vulnerability from being exploited by traffic that goes through the firewall.

CVE-2023-43615: Buffer overread in TLS stream cipher suites — Mbed TLS documentation

Mbed TLS 3.2.x through 3.4.x before 3.5 has a Buffer Overflow that can lead to remote Code execution.

**Title**

Buffer overflow in TLS handshake parsing with ECDH

**CVE**

CVE-2023-45199

**Date**

05 October 2023

**Affects**

Mbed TLS 3.2.0 and above

**Impact**

A remote attacker may cause arbitrary code execution.

**Severity**

HIGH

**Credit**

OSS-Fuzz

**Vulnerability**

A TLS 1.3 client or server configured with support for signature-based authentication (i.e. any non-PSK key exchange) is vulnerable to a heap buffer overflow. The server copies up to 65535 bytes in a buffer that is shorter. An unauthenticated malicious peer can overflow the TLS handshake structure by sending an overly long ECDH or FFDH public key.

A TLS 1.2 server configured with MBEDTLS_USE_PSA_CRYPTO and with support for a cipher suite using ECDH and a signature is vulnerable to a heap buffer overflow. An unauthenticated malicious peer can overflow the TLS handshake structure by sending an overly long ECDH public key. The server copies up to 255 bytes into a heap buffer that is sized for a valid public key, and thus shorter unless RSA or FFDH is enabled in addition to ECDH. TLS 1.2 clients, and builds without MBEDTLS_USE_PSA_CRYPTO are not affected.

**Impact**

A malicious peer can overflow a buffer on the heap with attacker-controlled data. This can often be escalated to remote code execution.

**Resolution**

Affected users will want to upgrade to Mbed TLS 3.5.0.

**Work-around**

The default configuration is not affected. Mbed TLS 2.28 is not affected.

In TLS 1.2, builds that support RSA or FFDH with keys of size at least 2048 bits in addition to ECDH are not affected. Note that the TLS 1.3 stack remains affected in that case.

Tag

#auth