Affected: opam: ocaml

## Bug description

OCaml versions 4.02.3 and earlier have a runtime bug that, on 64-bit platforms, causes sizes arguments to an internal memmove call to be sign-extended from 32 to 64-bits before being passed to the memmove function.

This leads arguments between 2GiB and 4GiB to be interpreted as larger than they are (specifically, a bit below 2^64), causing a buffer overflow.

Arguments between 4GiB and 6GiB are interpreted as 4GiB smaller than they should be, causing a possible information leak.

This commit fixes the bug: https://github.com/ocaml/ocaml/commit/659615c7b100a89eafe6253e7a5b9d84d0e8df74#diff-a97df53e3ebc59bb457191b496c90762 The function caml_bit_string is called indirectly from such functions as String.copy. String.copy for instance is supposed to be a "safe" function for which OCaml's memory safety guarantees apply.

Affected: opam: mirage-net-xen

## 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 identif…

Affected: opam: ocaml

## Description

Insufficient sanitisation in the OCaml compiler versions 4.04.0 and 4.04.1 allows external code to be executed with raised privilege in binaries marked as setuid, by setting the CAML_CPLUGINS, CAML_NATIVE_CPLUGINS, or CAML_BYTE_CPLUGINS environment variable.

Affected: opam: ocaml

## Bug description

The bigarray module in all recent ocaml versions is capable of reading in serialized (marshalled) objects from a external source which is often used for network operations and interprocess communication.

byterun/bigarray.c

Line 458 in ea60609 ```C b->data = malloc(elt_size * num_elts); ```

A integer overflow vulnerability allows under certain circumstances an remote attacker to input a corrupt object and edit arbitrary addresses in the processes memory which leads over common techniques (in this take libc one gadget but any rop gadget or got table vector would work) to arbitrary memory access (!) and in the course also arbitrary code execution

Please check the writeup.pdf for more details !!

In variations of this the exploit is usable in all ocaml versions we tested no matter if compiled to binary or intepreted (!)

## Steps to reproduce

Check out the attached archive and run the makefile (or use the precompile executable) the exploit can be run by executing exploit.py (python2.7 and pwntools are required) The last step of code execution is using a one-gadget attack technique and is specific to the glibc version in use (e.g. tested is debian glibc 2.24-11+deb9u1) but can with minimal amount of work be ported to any libc version on any patch level to our knowledge

Of course you can also use the exploit.py to write your own version of exploit

## Additional information

This Vulnerability in ocaml was discovered by me (maximilian.tschirschnitz@gmx.d…

Affected: opam: netchannel

## 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 ne…

Affected: opam: mirage-xen

## 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 shar…

Affected: opam: solo5

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

## Solution

The solution is to fix the console output code in solo5, as done in https://github.com/Solo5/solo5/pull/538/commits/099be86f0a17a619fcadbb970bb9e511d28d3cd8

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

Affected: opam: opam-repository

## Bug description

Opam uses since version 2.0.0 a download cache: if a source artifact is needed, first its hash is looked up in the local cache (~/.opam/download-cache/<hash-algorihm>/<hash>). Opam supports multiple hash algorithms, a cache lookup tries all hash algorithms present in the opam file. Before opam 2.1.5, the hash of a cache entry as encoded in its file name was trusted and not checked against its content.

If a package specifies only a single (non-weak) hash algorithm, this lead to the source artifact taken as is, any error while writing the artifact into the cache, or reading it from the cache, was not detected. Also, in certain setups, if the download cache is shared (writable) across containers (for example in some CI systems), this leads to the possibility of cache poisoning.

Thanks to Raja and Kate, the issue was fixed in [PR 5538](https://github.com/ocaml/opam/pull/5538)

## Timeline

The timeline of this issue is as follows:

- Feb 23rd 2023 conducted black-box security audit of opam - Feb 24th 2023 reported to the opam team - Feb 27th 2023 video meeting with the opam team, explaining the issue further - Mar 27th 2023 initial review meeting of the patches developed by the opam team - May 9th 2023 public PR fixing the issue discovered - May 25th 2023 release of opam 2.1.5

Affected: opam: albatross

## Background

Albatross-console reads the console output from multiple unikernel tenders (solo5-hvt). This console output can be retrieved using albatross-client.

The console protocol is fairly simple: the unikernel invokes a PUTS hypercall, which sends arbitrary bytes of given length to the unikernel tender (host, typically solo5-hvt), which writes them to a file descriptor.

albatross_console reads this output, and assumes it will be newline delimited, and keeps at most 1024 lines.

## Problem description

This helps guard against unlimited memory usage from runaway/long running unikernels, however it doesn't guard against malicious (or buggy) unikernels.

The problem is this line in albatross_console:

``` let rec loop () = Lwt_io.read_line channel ```

Unfortunately Lwt_io.read_line doesn't take a parameter to limit the size of the line that is read, so it is very easy for a unikernel to exhaust the memory of albatross_console: all it needs to do is to write a lot of bytes without ever writing a newline.

Tested with the Debian packages, but confirmed the above code to be present in latest master too: ``` $ /usr/libexec/albatross/albatross-console --version version v2.3.0-9-g5b14787 protocol version 5 ```

## Impact

A typical attack will look like this in albatross_console's logs: ``` Jun 07 16:41:18 ubuntu22 albatross-console[13721]: albatross-console: [WARNING] disconnected Jun 07 16:41:42 ubuntu22 albatross-console[13721]: albatross-console: [ERROR] except…

Affected: opam: ocaml

## Summary

A critical buffer over-read vulnerability in OCaml's Marshal deserialization (runtime/intern.c) enables remote code execution through a multi-phase attack chain. The vulnerability stems from missing bounds validation in the readblock() function, which performs unbounded memcpy() operations using attacker-controlled lengths from malicious Marshal data.

Please note that Marshal is not type safe, and you have to be careful if you use the deserialization on untrusted input (due to type confusion, and remote code execution by design - you can use Marshal for code).

Affected functions: `Marshal.from_channel`, `Marshal.from_bytes`, `Marshal.from_string`, `Stdlib.input_value`, `Pervasives.input_value` when reading data from an untrusted source.

## Vulnerability Attack Vector

Corrupted or malicious marshaled data that causes undefined behaviour in the runtime system when unmarshaled. `input_value` should either fail cleanly or produce a well-formed OCaml object, without corrupting the runtime system.

Consequently, this excludes:

* well-formed marshaled data that produces an OCaml object that is not of the type expected by the OCaml code and causes the Ocaml code to crash or misbehave

* misuses of the OCaml runtime system by the program performing input_value, such as setting `Debugger.function_placeholder` to the wrong function.

The former issue may be addressed at some point by validating the unmarshaled OCaml value against the expected type, using the functions…