<?xml version="1.0" encoding="UTF-8"?>
<cvrfdoc xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:cpe="http://cpe.mitre.org/language/2.0" xmlns:cvrf="http://docs.oasis-open.org/csaf/ns/csaf-cvrf/v1.2/cvrf" xmlns:cvrf-common="http://docs.oasis-open.org/csaf/ns/csaf-cvrf/v1.2/common" xmlns:cvssv2="http://scap.nist.gov/schema/cvss-v2/1.0" xmlns:cvssv3="https://www.first.org/cvss/cvss-v3.0.xsd" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:ns0="http://purl.org/dc/elements/1.1/" xmlns:prod="http://docs.oasis-open.org/csaf/ns/csaf-cvrf/v1.2/prod" xmlns:scap-core="http://scap.nist.gov/schema/scap-core/1.0" xmlns:sch="http://purl.oclc.org/dsdl/schematron" xmlns:vuln="http://docs.oasis-open.org/csaf/ns/csaf-cvrf/v1.2/vuln" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://docs.oasis-open.org/csaf/ns/csaf-cvrf/v1.2/cvrf">
  <DocumentTitle xml:lang="en">CVE-2024-2746</DocumentTitle>
  <DocumentType>SUSE CVE</DocumentType>
  <DocumentPublisher Type="Vendor">
    <ContactDetails>security@suse.de</ContactDetails>
    <IssuingAuthority>SUSE Security Team</IssuingAuthority>
  </DocumentPublisher>
  <DocumentTracking>
    <Identification>
      <ID>SUSE CVE-2024-2746</ID>
    </Identification>
    <Status>Interim</Status>
    <Version>1</Version>
    <RevisionHistory>
      <Revision>
        <Number>6</Number>
        <Date>2025-10-05T00:29:20Z</Date>
        <Description>current</Description>
      </Revision>
    </RevisionHistory>
    <InitialReleaseDate>2024-08-13T23:20:59Z</InitialReleaseDate>
    <CurrentReleaseDate>2025-10-05T00:29:20Z</CurrentReleaseDate>
    <Generator>
      <Engine>cve-database/bin/generate-cvrf-cve.pl</Engine>
      <Date>2020-12-27T01:00:00Z</Date>
    </Generator>
  </DocumentTracking>
  <DocumentNotes>
    <Note Title="CVE" Type="Summary" Ordinal="1" xml:lang="en">CVE-2024-2746</Note>
    <Note Title="Mitre CVE Description" Type="Description" Ordinal="2" xml:lang="en">Incomplete fix for CVE-2024-1929

The problem with CVE-2024-1929 was that the dnf5 D-Bus daemon accepted arbitrary configuration parameters from unprivileged users, which allowed a
local root exploit by tricking the daemon into loading a user controlled "plugin". All of this happened before Polkit authentication was even started.

The dnf5 library code does not check whether non-root users control the directory in question.  

On one hand, this poses a Denial-of-Service attack vector by making the daemonoperate on a blocking file (e.g. named FIFO special file) or a very large file
that causes an out-of-memory situation (e.g. /dev/zero). On the other hand, this can be used to let the daemon process privileged files like /etc/shadow.
The file in question is parsed as an INI file. Error diagnostics resulting from parsing privileged files could cause information leaks, if these diagnostics
are accessible to unprivileged users. In the case of libdnf5, no such user accessible diagnostics should exist, though.

Also, a local attacker can place a valid repository configuration file in this directory. This configuration file allows to specify
a plethora of additional configuration options. This makes various  additional code paths in libdnf5 accessible to the attacker.</Note>
    <Note Title="Terms of Use" Type="Legal Disclaimer" Ordinal="4" xml:lang="en">The CVRF data is provided by SUSE under the Creative Commons License 4.0 with Attribution (CC-BY-4.0).</Note>
  </DocumentNotes>
  <DocumentReferences>
    <Reference Type="Self">
      <URL>https://www.suse.com/support/security/rating/</URL>
      <Description>SUSE Security Ratings</Description>
    </Reference>
  </DocumentReferences>
  <ProductTree xmlns="http://docs.oasis-open.org/csaf/ns/csaf-cvrf/v1.2/prod"/>
  <Vulnerability xmlns="http://docs.oasis-open.org/csaf/ns/csaf-cvrf/v1.2/vuln" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">Incomplete fix for CVE-2024-1929

The problem with CVE-2024-1929 was that the dnf5 D-Bus daemon accepted arbitrary configuration parameters from unprivileged users, which allowed a
local root exploit by tricking the daemon into loading a user controlled "plugin". All of this happened before Polkit authentication was even started.

The dnf5 library code does not check whether non-root users control the directory in question.  

On one hand, this poses a Denial-of-Service attack vector by making the daemonoperate on a blocking file (e.g. named FIFO special file) or a very large file
that causes an out-of-memory situation (e.g. /dev/zero). On the other hand, this can be used to let the daemon process privileged files like /etc/shadow.
The file in question is parsed as an INI file. Error diagnostics resulting from parsing privileged files could cause information leaks, if these diagnostics
are accessible to unprivileged users. In the case of libdnf5, no such user accessible diagnostics should exist, though.

Also, a local attacker can place a valid repository configuration file in this directory. This configuration file allows to specify
a plethora of additional configuration options. This makes various  additional code paths in libdnf5 accessible to the attacker.</Note>
    </Notes>
    <CVE>CVE-2024-2746</CVE>
    <ProductStatuses/>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
  </Vulnerability>
</cvrfdoc>
