From 567db8fd522d50546ed8e1be77bddaff8654a3c7 Mon Sep 17 00:00:00 2001 From: Lucas Pluvinage Date: Wed, 4 Jan 2023 18:16:26 +0100 Subject: [PATCH] remove duplicate posts --- data/blog/MSA00.md | 113 ------------------------------------------- data/blog/MSA01.md | 101 -------------------------------------- data/blog/MSA02.md | 118 --------------------------------------------- data/blog/MSA03.md | 96 ------------------------------------ 4 files changed, 428 deletions(-) delete mode 100644 data/blog/MSA00.md delete mode 100644 data/blog/MSA01.md delete mode 100644 data/blog/MSA02.md delete mode 100644 data/blog/MSA03.md diff --git a/data/blog/MSA00.md b/data/blog/MSA00.md deleted file mode 100644 index 4c3cdfb5..00000000 --- a/data/blog/MSA00.md +++ /dev/null @@ -1,113 +0,0 @@ ---- -updated: 2016-5-3 -authors: -- name: Hannes Mehnert - uri: https://github.com/hannesm - email: hm519@cam.ac.uk -subject: 'MirageOS security advisory 00: mirage-net-xen' -permalink: MSA00 ---- - -## MirageOS Security Advisory 00 - memory disclosure in mirage-net-xen - -- Module: mirage-net-xen -- Announced: 2016-05-03 -- Credits: Enguerrand Decorne, Thomas Leonard, Hannes Mehnert, Mindy Preston -- Affects: mirage-net-xen <1.4.2 -- Corrected: 2016-01-08 1.5.0 release, 2016-05-03 1.4.2 release - -For general information regarding MirageOS Security Advisories, -please visit [https://mirage.io/security](https://mirage.io/security). - -Hannes published a [blog article](https://hannes.nqsb.io/Posts/BadRecordMac) about -the analysis of this issue. - -### Background - -MirageOS is a library operating system using cooperative multitasking, which can -be executed as a guest of the Xen hypervisor. Virtual devices, such as a -network device, share memory between MirageOS and the hypervisor. MirageOS -allocates and grants the hypervisor access to a ringbuffer containing pages to -be sent on the network device, and another ringbuffer with pages to be filled -with received data. A write on the MirageOS side consists of filling the page -with the packet data, submitting a write request to the hypervisor, and awaiting -a response from the hypervisor. To correlate the request with the response, a -16bit identifier is used. - -### Problem Description - -Generating this 16bit identifier was not done in a unique manner. When multiple -pages share an identifier, and are requested to be transmitted via the wire, the -first successful response will mark all pages with this identifier free, even -those still waiting to be transmitted. Once marked free, the MirageOS -application fills the page for another chunk of data. This leads to corrupted -packets being sent, and can lead to disclosure of memory intended for another -recipient. - -### Impact - -This issue discloses memory intended for another recipient. All versions before -mirage-net-xen 1.4.2 are affected. The receiving side uses a similar mechanism, -which may lead to corrupted incoming data (eventually even mutated while being -processed). - -Version 1.5.0, released on 8th January, already assigns unique identifiers for -transmission. Received pages are copied into freshly allocated buffers before -passed to the next layer. When 1.5.0 was released, the impact was not clear to -us. Version 1.6.1 now additionally ensures that received pages have a unique -identifier. - -### Workaround - -No workaround is available. - -### Solution - -The unique identifier is now generated in a unique manner using a monotonic -counter. - -Transmitting corrupt data and disclosing memory is fixed in versions 1.4.2 and -above. - -The recommended way to upgrade is: -```bash -opam update -opam upgrade mirage-net-xen -``` - -Or, explicitly: -```bash -opam upgrade -opam reinstall mirage-net-xen=1.4.2 -``` - -Affected releases have been marked uninstallable in the opam repository. - -### Correction details - -The following list contains the correction revision numbers for each -affected branch. - -Memory disclosure on transmit: - -master: [47de2edfad9c56110d98d0312c1a7e0b9dcc8fbf](https://github.com/mirage/mirage-net-xen/commit/47de2edfad9c56110d98d0312c1a7e0b9dcc8fbf) - -1.4: [ec9b1046b75cba5ae3473b2d3b223c3d1284489d](https://github.com/mirage/mirage-net-xen/commit/ec9b1046b75cba5ae3473b2d3b223c3d1284489d) - -Corrupt data while receiving: - -master: [0b1e53c0875062a50e2d5823b7da0d8e0a64dc37](https://github.com/mirage/mirage-net-xen/commit/0b1e53c0875062a50e2d5823b7da0d8e0a64dc37) - -1.4: [6daad38af2f0b5c58d6c1fb24252c3eed737ede4](https://github.com/mirage/mirage-net-xen/commit/6daad38af2f0b5c58d6c1fb24252c3eed737ede4) - -### References - -[mirage-net-xen](https://github.com/mirage/mirage-net-xen) - -You can find the latest version of this advisory online at -[https://mirage.io/blog/MSA00](https://mirage.io/blog/MSA00). - -This advisory is signed using OpenPGP, you can verify the signature -by downloading our public key from a keyserver (`gpg --recv-key 4A732D757C0EDA74`), -downloading the raw markdown source of this advisory from [GitHub](https://raw.githubusercontent.com/mirage/mirage-www/master/data/security/00.txt.asc) -and executing `gpg --verify 00.md.asc`. diff --git a/data/blog/MSA01.md b/data/blog/MSA01.md deleted file mode 100644 index 57595e43..00000000 --- a/data/blog/MSA01.md +++ /dev/null @@ -1,101 +0,0 @@ ---- -updated: 2019-03-21 -authors: -- name: Mindy Preston - uri: https://github.com/yomimono - email: mindy.preston@cl.cam.ac.uk -subject: 'MirageOS security advisory 01: netchannel 1.10.0' -permalink: MSA01 ---- - -## MirageOS Security Advisory 01 - memory disclosure in mirage-net-xen - -- Module: netchannel -- Announced: 2019-03-21 -- Credits: Thomas Leonard, Hannes Mehnert, Mindy Preston -- Affects: netchannel = 1.10.0 -- Corrected: 2019-03-20 1.10.1 release - -For general information regarding MirageOS Security Advisories, -please visit [https://mirage.io/security](https://mirage.io/security). - -### Background - -MirageOS is a library operating system using cooperative multitasking, which can -be executed as a guest of the Xen hypervisor. Virtual devices, such as a -network device, share memory between MirageOS and the hypervisor. To maintain -adequate performance, the virtual device managing network communication between -MirageOS and the Xen hypervisor maintains a shared pool of pages and reuses -them for write requests. - -### Problem Description - -In version 1.10.0 of netchannel, the API for handling network requests -changed to provide higher-level network code with an interface for writing into -memory directly. As part of this change, code paths which exposed memory taken -from the shared page pool did not ensure that previous data had been cleared -from the buffer. This error resulted in memory which the user did not -overwrite staying resident in the buffer, and potentially being sent as part of -unrelated network communication. - -The mirage-tcpip library, which provides interfaces for higher-level operations -like IPv4 and TCP header writes, assumes that buffers into which it writes have -been zeroed, and therefore may not explicitly write some fields which are always -zero. As a result, some packets written with netchannel v1.10.0 which were -passed to mirage-tcpip with nonzero data will have incorrect checksums -calculated and will be discarded by the receiver. - -### Impact - -This issue discloses memory intended for another recipient and corrupts packets. -Only version 1.10.0 of netchannel is affected. Version 1.10.1 fixes this issue. - -Version 1.10.0 was available for less than one month and many upstream users -had not yet updated their own API calls to use it. In particular, no version of -qubes-mirage-firewall or its dependency mirage-nat compatible with version -1.10.0 was released. - -### Workaround - -No workaround is available. - -### Solution - -Transmitting corrupt data and disclosing memory is fixed in version 1.10.1. - -The recommended way to upgrade is: -```bash -opam update -opam upgrade netchannel -``` - -Or, explicitly: -```bash -opam upgrade -opam reinstall netchannel=1.10.1 -``` - -Affected releases (version 1.10.0 of netchannel and mirage-net-xen) have been marked uninstallable in the opam repository. - -### Correction details - -The following list contains the correction revision numbers for each -affected branch. - -Memory disclosure on transmit: - -master: [6c7a13a5dae0f58dcc0653206a73fa3d8174b6d2](https://github.com/mirage/mirage-net-xen/commit/6c7a13a5dae0f58dcc0653206a73fa3d8174b6d2) - -1.10.0: [bd0382eabe17d0824c8ba854ec935d8a2e5f7489](https://github.com/mirage/mirage-net-xen/commit/bd0382eabe17d0824c8ba854ec935d8a2e5f7489) - -### References - -[netchannel](https://github.com/mirage/mirage-net-xen) - -You can find the latest version of this advisory online at -[https://mirage.io/blog/MSA01](https://mirage.io/blog/MSA01). - -This advisory is signed using OpenPGP, you can verify the signature -by downloading our public key from a keyserver (`gpg --recv-key 4A732D757C0EDA74`), -downloading the raw markdown source of this advisory from [GitHub](https://raw.githubusercontent.com/mirage/mirage-www/master/data/security/01.txt.asc) -and executing `gpg --verify 01.txt.asc`. diff --git a/data/blog/MSA02.md b/data/blog/MSA02.md deleted file mode 100644 index 7a3a0224..00000000 --- a/data/blog/MSA02.md +++ /dev/null @@ -1,118 +0,0 @@ ---- -updated: 2019-04-26 -authors: -- name: Thomas Leonard - uri: http://roscidus.com/blog/ - email: talex5@gmail.com -subject: 'MirageOS security advisory 02: mirage-xen < 3.3.0' -permalink: MSA02 ---- - -## MirageOS Security Advisory 02 - grant unshare vulnerability in mirage-xen - -- Module: mirage-xen -- Announced: 2019-04-25 -- Credits: Thomas Leonard, Mindy Preston -- Affects: mirage-xen < 3.3.0, - mirage-block-xen < 1.6.1, - mirage-net-xen < 1.10.2, - mirage-console < 2.4.2, - ocaml-vchan < 4.0.2, - ocaml-gnt (no longer supported) -- Corrected: 2019-04-22: mirage-xen 3.4.0, - 2019-04-05: mirage-block-xen 1.6.1, - 2019-04-02: mirage-net-xen 1.10.2, - 2019-03-27: mirage-console 2.4.2, - 2019-03-27: ocaml-vchan 4.0.2 - -For general information regarding MirageOS Security Advisories, -please visit [https://mirage.io/security](https://mirage.io/security). - -### Background - -MirageOS is a library operating system using cooperative multitasking, which can -be executed as a guest of the Xen hypervisor. Virtual machines running on a Xen -host can communicate by sharing pages of memory. For example, when a Mirage VM -wants to use a virtual network device provided by a Linux dom0: - -1. The Mirage VM reserves some of its memory for this purpose and writes an entry - to its *grant table* to say that dom0 should have access to it. -2. The Mirage VM tells dom0 (via XenStore) about the grant. -3. dom0 asks Xen to map the memory into its address space. - -The Mirage VM and dom0 can now communicate using this shared memory. -When dom0 has finished with the memory: - -1. dom0 tells Xen to unmap the memory from its address space. -2. dom0 tells the Mirage VM that it no longer needs the memory. -3. The Mirage VM removes the entry from its grant table. -4. The Mirage VM may reuse the memory for other purposes. - -### Problem Description - -Mirage removes the entry by calling the [gnttab_end_access][] function in Mini-OS. -This function checks whether the remote domain still has the memory mapped. If so, -it returns 0 to indicate that the entry cannot be removed yet. To make this function -available to OCaml code, the [stub_gntshr_end_access][] C stub in mirage-xen wrapped this -with the OCaml calling conventions. Unfortunately, it ignored the return code and reported -success in all cases. - -### Impact - -A malicious VM can tell a MirageOS unikernel that it has finished using some -shared memory while it is still mapped. The Mirage unikernel will think that -the unshare operation has succeeded and may reuse the memory, or allow it to be -garbage collected. The malicious VM will still have access to the memory. - -In many cases (such as in the example above) the remote domain will be dom0, -which is already fully trusted. However, if a unikernel shares memory with an -untrusted domain then there is a problem. - -### Workaround - -No workaround is available. - -### Solution - -Returning the result from the C stub required changes to the OCaml grant API to -deal with the result. This turned out to be difficult because, for historical -reasons, the OCaml part of the API was in the ocaml-gnt package while the C stubs -were in mirage-xen, and because the C stubs are also shared with the Unix backend. - -We instead created a [new grant API][] in mirage-xen, migrated all existing -Mirage drivers to use it, and then dropped support for the old API. -mirage-xen 3.3.0 added support for the new API and 3.4.0 removed support for the -old one. - -The recommended way to upgrade is: -```bash -opam update -opam upgrade mirage-xen -``` - -### Correction details - -The following PRs were part of the fix: - -- [mirage-xen/pull/9](https://github.com/mirage/mirage-xen/pull/9) - Add grant-handling code to OS.Xen -- [mirage-net-xen/pull/85](https://github.com/mirage/mirage-net-xen/pull/85) - Use new OS.Xen API for grants -- [ocaml-vchan/pull/125](https://github.com/mirage/ocaml-vchan/pull/125) - Update to new OS.Xen grant API -- [mirage-block-xen/pull/79](https://github.com/mirage/mirage-block-xen/pull/79) - Port to new grant interface provided by mirage-xen -- [mirage-console/pull/75](https://github.com/mirage/mirage-console/pull/75) - Use new grant interface in mirage-xen -- [mirage-xen/pull/12](https://github.com/mirage/mirage-xen/pull/12) - Drop support for old ocaml-gnt package - -### References - -You can find the latest version of this advisory online at -[https://mirage.io/blog/MSA02](https://mirage.io/blog/MSA02). - -This advisory is signed using OpenPGP, you can verify the signature -by downloading our public key from a keyserver (`gpg --recv-key -4A732D757C0EDA74`), -downloading the raw markdown source of this advisory from -[GitHub](https://raw.githubusercontent.com/mirage/mirage-www/master/data/security/02.txt.asc) -and executing `gpg --verify 02.txt.asc`. - -[gnttab_end_access]: https://github.com/mirage/mini-os/blob/94cb25eb73e58e5c825c1ad5f6cf3d2647603a50/gnttab.c#L98 -[stub_gntshr_end_access]: https://github.com/mirage/mirage-xen/blob/v3.2.0/bindings/gnttab_stubs.c#L227 -[new grant API]: https://github.com/mirage/mirage-xen/pull/9 diff --git a/data/blog/MSA03.md b/data/blog/MSA03.md deleted file mode 100644 index f5f75753..00000000 --- a/data/blog/MSA03.md +++ /dev/null @@ -1,96 +0,0 @@ ---- -updated: 2022-12-07 -authors: -- name: Hannes Mehnert - uri: http://hannes.robur.coop -- name: Pierre Alain - uri: https://github.com/palainp -subject: 'MirageOS security advisory 03: xen with solo5 >= 0.6.6 & < 0.7.5' -permalink: MSA03 ---- - -## MirageOS Security Advisory 03 - infinite loop in console output on xen - -- Module: solo5 -- Announced: 2022-12-07 -- Credits: Krzysztof Burghardt, Pierre Alain, Thomas Leonard, Hannes Mehnert -- Affects: solo5 >= 0.6.6 & < 0.7.5, - qubes-mirage-firewall >= 0.8.0 & < 0.8.4 -- Corrected: 2022-12-07: solo5 0.7.5, - 2022-12-07: qubes-mirage-firewall 0.8.4 -- CVE: CVE-2022-46770 - -For general information regarding MirageOS Security Advisories, -please visit [https://mirage.io/security](https://mirage.io/security). - -### Background - -MirageOS is a library operating system using cooperative multitasking, which can -be executed as a guest of the Xen hypervisor. Output on the console is performed -via the Xen console protocol. - -### Problem Description - -Since MirageOS moved from PV mode to PVH, and thus replacing Mini-OS with solo5, -there was an issue in the solo5 code which failed to properly account the -already written bytes on the console. This only occurs if the output to be -performed does not fit in a single output buffer (2048 bytes on Xen). - -The code in question set the number of bytes written to the last written count -(written = output_some(buf)), instead of increasing the written count -(written += output_some(buf)). - -### Impact - -Console output may lead to an infinite loop, endlessly printing data onto the -console. - -A prominent unikernel is the Qubes MirageOS firewall, which prints some input -packets onto the console. This can lead to a remote denial of service -vulnerability, since any client could send a malformed and sufficiently big -network packet. - -### Workaround - -No workaround is available. - -### Solution - -The solution is to fix the console output code in solo5, as done in -https://github.com/Solo5/solo5/pull/538/commits/099be86f0a17a619fcadbb970bb9e511d28d3cd8 - -For the qubes-mirage-firewall, update to a solo5 release (0.7.5) which has the -issue fixed. This has been done in the release 0.8.4 of qubes-mirage-firewall. - -The recommended way to upgrade is: -```bash -opam update -opam upgrade solo5 -``` - -### Correction details - -The following PRs were part of the fix: - -- [solo5/pull/538](https://github.com/Solo5/solo5/pull/538) - xen console: update the "to be written" count -- [qubes-mirage-firewall/pull/167](https://github.com/mirage/qubes-mirage-firewall/pull/167) - update opam repository commit - -### Timeline - -- 2022-12-04: initial report by Krzysztof Burghardt https://github.com/mirage/qubes-mirage-firewall/issues/166 -- 2022-12-04: investigation by Hannes Mehnert and Pierre Alain -- 2022-12-05: initial fix by Pierre Alain https://github.com/Solo5/solo5/pull/538 -- 2022-12-05: review of fix by Thomas Leonard -- 2022-12-07: release of fixed packages and security advisory - -### References - -You can find the latest version of this advisory online at -[https://mirage.io/blog/MSA03](https://mirage.io/blog/MSA03). - -This advisory is signed using OpenPGP, you can verify the signature -by downloading our public key from a keyserver (`gpg --recv-key -4A732D757C0EDA74`), -downloading the raw markdown source of this advisory from -[GitHub](https://raw.githubusercontent.com/mirage/mirage-www/master/data/security/03.txt.asc) -and executing `gpg --verify 03.txt.asc`.