An issue was discovered in the PageTriage 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. Usernames of hidden users are exposed.

Auth Login

Click the _MediaWiki_ button below to connect your Wikimedia unified account. Alternatively, click the _Wikitech Account (LDAP)_ button to connect your Developer account credentials.  
In case of doubt, check the Phabricator Help.

LDAP Username

LDAP Password

Trouble logging in? Send a login link to your email address.

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-45369: Log In or Register with LDAP

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 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 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 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

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

In FW-PackageManager, there is a possible missing permission check. This could lead to local escalation of privilege with System execution privileges needed

CVE-2023-40654

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.

Source

CVE