GNU patch does not properly sanitize patch files allowing for malicious patches to pass arbitrary shell commands to ed. An attacker could exploit this by tricking a user into applying malicious patches with the patch command.
Created patch tracking bugs for this issue: Affects: fedora-all [bug 1564327]
There is some discussion at: http://rachelbythebay.com/w/2018/04/05/bangpatch/ The OpenBSD patch tries to fix up interpretation of s// commands on their way to ed. The FreeBSD patch does this and also switches to /usr/bin/red (restricted-mode ed), which is supposed to be safer. On first glance, GNU patch's interpretation of the stream passed to ed is much more naive. The "correct" thing would be to invoke /usr/bin/red (on the assumption that patches shouldn't be able to execute arbitrary commands). It also looks like GNU patch ignores -c -e -n -u options to specify the patch type, instead calling intuit_diff_type for each file header.
Upstream ticket: https://savannah.gnu.org/bugs/?53566
Two proposed patches are already attached upstream. Of those, Saleem Rashid's "Refuse to apply ed scripts by default" seems pretty solid, as it asks the user before each potential invocation of ed. This protects against bugs in restricted-ed as well, which seems wise. It also includes tests, and allows override with "-f" in case auto build systems want to enable ed for some reason. The risk remains that existing build systems already use -f, so they will be unprotected.
Upstream patch: http://git.savannah.gnu.org/cgit/patch.git/commit/?id=123eaff0d5d1aebe128295959435b9ca5909c26d Includes test suite which covers the cases identified here, and more. This forces ed to quit on invalid commands, preventing this injection. Patch applies quite strict validation to ed scripts, so hopefully this is the only missing piece. Invoking "ed -r" is still probably a good defense-in-depth mechanism, as further injections may be present or introduced by future changes in ed or patch.
This issue has been addressed in the following products: Red Hat Enterprise Linux 6 Via RHSA-2018:1199 https://access.redhat.com/errata/RHSA-2018:1199
This issue has been addressed in the following products: Red Hat Enterprise Linux 7 Via RHSA-2018:1200 https://access.redhat.com/errata/RHSA-2018:1200
This issue has been addressed in the following products: Red Hat Enterprise Linux 6.5 Advanced Update Support Via RHSA-2018:2096 https://access.redhat.com/errata/RHSA-2018:2096
This issue has been addressed in the following products: Red Hat Enterprise Linux 7.2 Advanced Update Support Red Hat Enterprise Linux 7.2 Update Services for SAP Solutions Red Hat Enterprise Linux 7.2 Telco Extended Update Support Via RHSA-2018:2093 https://access.redhat.com/errata/RHSA-2018:2093
This issue has been addressed in the following products: Red Hat Enterprise Linux 6.6 Advanced Update Support Red Hat Enterprise Linux 6.6 Telco Extended Update Support Via RHSA-2018:2095 https://access.redhat.com/errata/RHSA-2018:2095
This issue has been addressed in the following products: Red Hat Enterprise Linux 6.7 Extended Update Support Via RHSA-2018:2094 https://access.redhat.com/errata/RHSA-2018:2094
This issue has been addressed in the following products: Red Hat Enterprise Linux 6.4 Advanced Update Support Via RHSA-2018:2097 https://access.redhat.com/errata/RHSA-2018:2097
This issue has been addressed in the following products: Red Hat Enterprise Linux 7.3 Extended Update Support Via RHSA-2018:2092 https://access.redhat.com/errata/RHSA-2018:2092
This issue has been addressed in the following products: Red Hat Enterprise Linux 7.4 Extended Update Support Via RHSA-2018:2091 https://access.redhat.com/errata/RHSA-2018:2091