Bug 1938027

Use the following template to for the 'fedpkg update' request to submit an
update for this issue as it contains the top-level parent bug(s) as well as
this tracking bug.  This will ensure that all associated bugs get updated
when new packages are pushed to stable.

=====

# bugfix, security, enhancement, newpackage (required)
type=security

# low, medium, high, urgent (required)
severity=low

# testing, stable
request=testing

# Bug numbers: 1234,9876
bugs=1934125,1938027

# Description of your update
notes=Security fix for [PUT CVEs HERE]

# Enable request automation based on the stable/unstable karma thresholds
autokarma=True
stable_karma=3
unstable_karma=-3

# Automatically close bugs when this marked as stable
close_bugs=True

# Suggest that users restart after update
suggest_reboot=False

======

Additionally, you may opt to use the bodhi web interface to submit updates:

https://bodhi.fedoraproject.org/updates/new

(In reply to Todd Cullum from comment #1)
> Use the following template to for the 'fedpkg update' request to submit an
> update for this issue as it contains the top-level parent bug(s) as well as
> this tracking bug.  This will ensure that all associated bugs get updated
> when new packages are pushed to stable.
> 
> =====
> 
> # bugfix, security, enhancement, newpackage (required)
> type=security
> 
> # low, medium, high, urgent (required)
> severity=low
> 
> # testing, stable
> request=testing
> 
> # Bug numbers: 1234,9876
> bugs=1934125,1938027
> 
> # Description of your update
> notes=Security fix for [PUT CVEs HERE]
> 
> # Enable request automation based on the stable/unstable karma thresholds
> autokarma=True
> stable_karma=3
> unstable_karma=-3
> 
> # Automatically close bugs when this marked as stable
> close_bugs=True
> 
> # Suggest that users restart after update
> suggest_reboot=False
> 
> ======
> 
> Additionally, you may opt to use the bodhi web interface to submit updates:
> 
> https://bodhi.fedoraproject.org/updates/new

This is severity=critical, not severity=low, and should be request=stable.
Fedora does not sign its metadata, which means this is a critical remote code
execution vulnerability.

(In reply to Demi Marie Obenour from comment #2)
> (In reply to Todd Cullum from comment #1)
> > Use the following template to for the 'fedpkg update' request to submit an
> > update for this issue as it contains the top-level parent bug(s) as well as
> > this tracking bug.  This will ensure that all associated bugs get updated
> > when new packages are pushed to stable.
> > 
> > =====
> > 
> > # bugfix, security, enhancement, newpackage (required)
> > type=security
> > 
> > # low, medium, high, urgent (required)
> > severity=low
> > 
> > # testing, stable
> > request=testing
> > 
> > # Bug numbers: 1234,9876
> > bugs=1934125,1938027
> > 
> > # Description of your update
> > notes=Security fix for [PUT CVEs HERE]
> > 
> > # Enable request automation based on the stable/unstable karma thresholds
> > autokarma=True
> > stable_karma=3
> > unstable_karma=-3
> > 
> > # Automatically close bugs when this marked as stable
> > close_bugs=True
> > 
> > # Suggest that users restart after update
> > suggest_reboot=False
> > 
> > ======
> > 
> > Additionally, you may opt to use the bodhi web interface to submit updates:
> > 
> > https://bodhi.fedoraproject.org/updates/new
> 
> This is severity=critical, not severity=low, and should be request=stable.
> Fedora does not sign its metadata, which means this is a critical remote code
> execution vulnerability.

Would you please explain why you feel that this is critical[1] in more detail? What would an attack look like? Not in code, but conceptually. If I am an attacker, what would I need to do to exploit a victim, step-by-step?



IIUC, this requires a modified RPM which is NOT present in the repositories. So that means that an attacker would need to gain access to modify the repository content or convince a user to install an RPM from a third party location, or perform at least a man-in-the-middle attack, modifying the RPM. If this were to occur, many other bad things can happen. Please try to be thorough so I can be sure nothing was missed here. Thank you.

1. https://access.redhat.com/security/updates/classification

(In reply to Todd Cullum from comment #3)
> (In reply to Demi Marie Obenour from comment #2)
> > (In reply to Todd Cullum from comment #1)
> > > Use the following template to for the 'fedpkg update' request to submit an
> > > update for this issue as it contains the top-level parent bug(s) as well as
> > > this tracking bug.  This will ensure that all associated bugs get updated
> > > when new packages are pushed to stable.
> > > 
> > > =====
> > > 
> > > # bugfix, security, enhancement, newpackage (required)
> > > type=security
> > > 
> > > # low, medium, high, urgent (required)
> > > severity=low
> > > 
> > > # testing, stable
> > > request=testing
> > > 
> > > # Bug numbers: 1234,9876
> > > bugs=1934125,1938027
> > > 
> > > # Description of your update
> > > notes=Security fix for [PUT CVEs HERE]
> > > 
> > > # Enable request automation based on the stable/unstable karma thresholds
> > > autokarma=True
> > > stable_karma=3
> > > unstable_karma=-3
> > > 
> > > # Automatically close bugs when this marked as stable
> > > close_bugs=True
> > > 
> > > # Suggest that users restart after update
> > > suggest_reboot=False
> > > 
> > > ======
> > > 
> > > Additionally, you may opt to use the bodhi web interface to submit updates:
> > > 
> > > https://bodhi.fedoraproject.org/updates/new
> > 
> > This is severity=critical, not severity=low, and should be request=stable.
> > Fedora does not sign its metadata, which means this is a critical remote code
> > execution vulnerability.
> 
> Would you please explain why you feel that this is critical[1] in more
> detail? What would an attack look like? Not in code, but conceptually. If I
> am an attacker, what would I need to do to exploit a victim, step-by-step?
> 
> 
> 
> IIUC, this requires a modified RPM which is NOT present in the repositories.
> So that means that an attacker would need to gain access to modify the
> repository content or convince a user to install an RPM from a third party
> location, or perform at least a man-in-the-middle attack, modifying the RPM.
> If this were to occur, many other bad things can happen. Please try to be
> thorough so I can be sure nothing was missed here. Thank you.
> 
> 1. https://access.redhat.com/security/updates/classification

An attacker would need to perform all of the following:

1. Obtain a rogue certificate for mirrors.fedoraproject.org, signed by a
   trusted CA.  This is difficult, but has been done in the past by high-level
   attackers.
   
2. Obtain an on-path network position, such as by DNS poisoning, BGP hijacking,
   convincing the user to connect to a wireless network they control,
   compromising the user’s gateway, or running a rogue DHCP server.
   
3. Serve a modified metalink file that points to a repository they control.

In short, this bug completely nullifies gpgcheck=True.  I think we can agree
that gpgcheck=False is an insecure configuration unless repo_gpgcheck=True
is set.  And on Fedora and CentOS, it is not.

Also, the detailed description of this bug matches the description of
CVE-2021-3421 (string injection), not CVE-2021-20271 (signature check bypass).

> An attacker would need to perform all of the following:
> 
> 1. Obtain a rogue certificate for mirrors.fedoraproject.org, signed by a
>    trusted CA.  This is difficult, but has been done in the past by
> high-level
>    attackers.
>    
> 2. Obtain an on-path network position, such as by DNS poisoning, BGP
> hijacking,
>    convincing the user to connect to a wireless network they control,
>    compromising the user’s gateway, or running a rogue DHCP server.
>    
> 3. Serve a modified metalink file that points to a repository they control.
> 
> In short, this bug completely nullifies gpgcheck=True.  I think we can agree
> that gpgcheck=False is an insecure configuration unless repo_gpgcheck=True
> is set.  And on Fedora and CentOS, it is not.

Based off of this, other information, and the CVE confusion mentioned in Comment#5 , I've increased this from Low to Moderate. See below reasoning for why not Critical:

1. This is not Critical as defined on https://access.redhat.com/security/updates/classification . A Critical would be something like a program that is shipped and run by default on every single OS instance in which the victim could have their box taken over by an attacker just being online due to an extremely simple, repeatable, payload being sent to an open port. This (or anything near this) is clearly not the case here.

2. In fact, I would argue that it's not even fitting the description of an Important which states - "This rating is given to flaws that can **easily** compromise the confidentiality, integrity or availability of resources." I would not consider the attack scenario you described as "easy", in comparison with other vulnerabilities where e.g., a server receives a request and replies with confidential information, or allows remote code execution unauthenticated by simply receiving some requests.


This is not to say that this vulnerability is not significant. But the definition of Moderate on aforementioned page is:

>This rating is given to flaws that may be more difficult to exploit but could still lead to some >compromise of the confidentiality, integrity or availability of resources under certain circumstances. >These are the types of vulnerabilities that could have had a Critical or Important impact but are less >easily exploited based on a technical evaluation of the flaw, and/or affect unlikely configurations. 

The steps needed for an attacker to perform this seem to make this flaw best fit as a Moderate. The "certain circumstances" here map directly to your steps 1, 2, and 3 above.

In fact, even by CVSSv3 score definition[1], this is "Attack Complexity: High"

>A successful attack depends on conditions beyond the attacker's control. That is, a successful attack >cannot be accomplished at will, but requires the attacker to invest in some measurable amount of effort >in preparation or execution against the vulnerable component before a successful attack can be >expected.[^2] For example, a successful attack may depend on an attacker overcoming any of the >following conditions:

>    The attacker must gather knowledge about the environment in which the vulnerable target/component >exists. For example, a requirement to collect details on target configuration settings, sequence >numbers, or shared secrets.
>    The attacker must prepare the target environment to improve exploit reliability. For example, >repeated exploitation to win a race condition, or overcoming advanced exploit mitigation techniques.
>    **The attacker must inject themselves into the logical network path between the target and the >resource requested by the victim in order to read and/or modify network communications (e.g., a man in >the middle attack).**


1. https://www.first.org/cvss/specification-document

(In reply to Todd Cullum from comment #6)
> > An attacker would need to perform all of the following:
> > 
> > 1. Obtain a rogue certificate for mirrors.fedoraproject.org, signed by a
> >    trusted CA.  This is difficult, but has been done in the past by
> >    high-level
> >    attackers.
> >    
> > 2. Obtain an on-path network position, such as by DNS poisoning, BGP
> >    hijacking,
> >    convincing the user to connect to a wireless network they control,
> >    compromising the user’s gateway, or running a rogue DHCP server.
> >    
> > 3. Serve a modified metalink file that points to a repository they control.
> > 
> > In short, this bug completely nullifies gpgcheck=True.  I think we can agree
> > that gpgcheck=False is an insecure configuration unless repo_gpgcheck=True
> > is set.  And on Fedora and CentOS, it is not.
> 
> Based off of this, other information, and the CVE confusion mentioned in
> Comment#5 , I've increased this from Low to Moderate. See below reasoning
> for why not Critical:
> 
> 1. This is not Critical as defined on
> https://access.redhat.com/security/updates/classification . A Critical would
> be something like a program that is shipped and run by default on every
> single OS instance in which the victim could have their box taken over by an
> attacker just being online due to an extremely simple, repeatable, payload
> being sent to an open port. This (or anything near this) is clearly not the
> case here.
> 
> 2. In fact, I would argue that it's not even fitting the description of an
> Important which states - "This rating is given to flaws that can **easily**
> compromise the confidentiality, integrity or availability of resources." I
> would not consider the attack scenario you described as "easy", in
> comparison with other vulnerabilities where e.g., a server receives a
> request and replies with confidential information, or allows remote code
> execution unauthenticated by simply receiving some requests.

I also would not consider this to be easy to exploit.  Thank you for the
update.

> This is not to say that this vulnerability is not significant. But the
> definition of Moderate on aforementioned page is:
> 
> > This rating is given to flaws that may be more difficult to exploit but could still lead to some
> > compromise of the confidentiality, integrity or availability of resources under certain circumstances.
> > These are the types of vulnerabilities that could have had a Critical or Important impact but are less
> > easily exploited based on a technical evaluation of the flaw, and/or affect unlikely configurations. 
> 
> The steps needed for an attacker to perform this seem to make this flaw best
> fit as a Moderate. The "certain circumstances" here map directly to your
> steps 1, 2, and 3 above.

That makes sense, thanks!

> In fact, even by CVSSv3 score definition[1], this is "Attack Complexity:
> High"
> 
> > A successful attack depends on conditions beyond the attacker's control. That is, a successful attack
> > cannot be accomplished at will, but requires the attacker to invest in some measurable amount of effort
> > in preparation or execution against the vulnerable component before a successful attack can be
> > expected.[^2] For example, a successful attack may depend on an attacker overcoming any of the
> > following conditions:
> 
> >    The attacker must gather knowledge about the environment in which the vulnerable target/component
> >    exists. For example, a requirement to collect details on target configuration settings, sequence
> >    numbers, or shared secrets.
> >    The attacker must prepare the target environment to improve exploit reliability. For example,
> >    repeated exploitation to win a race condition, or overcoming advanced exploit mitigation techniques.
> >    **The attacker must inject themselves into the logical network path between the target and the
> >    resource requested by the victim in order to read and/or modify network communications (e.g., a man in
> >    the middle attack).**
> 
> 
> 1. https://www.first.org/cvss/specification-document

Agreed

FEDORA-2021-2383d950fd has been submitted as an update to Fedora 34. https://bodhi.fedoraproject.org/updates/FEDORA-2021-2383d950fd

FEDORA-2021-8d52a8a999 has been submitted as an update to Fedora 33. https://bodhi.fedoraproject.org/updates/FEDORA-2021-8d52a8a999

FEDORA-2021-662680e477 has been submitted as an update to Fedora 32. https://bodhi.fedoraproject.org/updates/FEDORA-2021-662680e477

FEDORA-2021-2383d950fd has been pushed to the Fedora 34 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2021-2383d950fd`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2021-2383d950fd

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

FEDORA-2021-8d52a8a999 has been pushed to the Fedora 33 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2021-8d52a8a999`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2021-8d52a8a999

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

FEDORA-2021-662680e477 has been pushed to the Fedora 32 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2021-662680e477`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2021-662680e477

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

FEDORA-2021-2383d950fd has been pushed to the Fedora 34 stable repository.
If problem still persists, please make note of it in this bug report.

FEDORA-2021-8d52a8a999 has been pushed to the Fedora 33 stable repository.
If problem still persists, please make note of it in this bug report.

FEDORA-2021-662680e477 has been pushed to the Fedora 32 stable repository.
If problem still persists, please make note of it in this bug report.

Is there any reason why it is not pushed to RHEL 7? It's a major bug...

Thanks.

This message is a reminder that Fedora 33 is nearing its end of life.
Fedora will stop maintaining and issuing updates for Fedora 33 on 2021-11-30.
It is Fedora's policy to close all bug reports from releases that are no longer
maintained. At that time this bug will be closed as EOL if it remains open with a
Fedora 'version' of '33'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 33 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

This message is a reminder that Fedora 33 is nearing its end of life.
Fedora will stop maintaining and issuing updates for Fedora 33 on 2021-11-30.
It is Fedora's policy to close all bug reports from releases that are no longer
maintained. At that time this bug will be closed as EOL if it remains open with a
Fedora 'version' of '33'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 33 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

This message is a reminder that Fedora 33 is nearing its end of life.
Fedora will stop maintaining and issuing updates for Fedora 33 on 2021-11-30.
It is Fedora's policy to close all bug reports from releases that are no longer
maintained. At that time this bug will be closed as EOL if it remains open with a
Fedora 'version' of '33'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 33 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Fedora 33 changed to end-of-life (EOL) status on 2021-11-30. Fedora 33 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.