I reviewed dotnet6 6.0.120 as checked into Mantic. This shouldn't be
considered a full audit but rather a quick gauge of maintainability.
dotnet6 is an open-source platform for building desktop, web, and mobile
applications that can run natively on any operating system. The dotnet
system includes tools, libraries, and languages that support modern,
scalable, and high-performance software development.
- CVE History:
- CVE-2022-38013: Fixed in 6.0.109
- CVE-2022-41032: Fixed in 6.0.110
- CVE-2023-21538: Fixed in 6.0.113
- CVE-2023-24936: Fixed in 6.0.118
- CVE-2023-28260: Fixed in 6.0.116
- CVE-2023-29331: Fixed in 6.0.118
- CVE-2023-29337: Fixed in 6.0.118
- CVE-2023-32032: Fixed in 6.0.118
- CVE-2023-33128: Fixed in 6.0.118
- CVE-2023-33170: Fixed in 6.0.120
- Build-Depends?
- clang
- cmake
- bash-completion
- debhelper-compat (= 13)
- dotnet-sdk-6.0
- dotnet-sdk-6.0-source-built-artifacts
- git
- libicu-dev
- libkrb5-dev
- liblttng-ust-dev
- libssl-dev
- libunwind-dev
- lld
- llvm
- locales-all
- python3
- zlib1g-dev
- pre/post inst/rm scripts?
- None
- init scripts?
- None
- systemd units?
- None
- dbus services?
- None
- setuid binaries?
- no `suid` or `sgid` binaries
- binaries in PATH?
- dotnet6, dotnet-host, dotnet-hostfxr-6.0, dotnet-runtime-6.0,
aspnetcore-runtime-6.0, dotnet-templates-6.0, dotnet-sdk-6.0,
dotnet-targeting-pack-6.0, netstandard-targeting-pack-2.1,
aspnetcore-targeting-pack-6.0, dotnet-apphost-pack-6.0
- sudo fragments?
- None
- polkit files?
- None
- udev rules?
- None
- unit tests / autopkgtests?
- Yes, autopkgtests runs fine locally passing all the tests
- cron jobs?
- None
- Build logs:
- same lintian errors described in https://bugs.launchpad.net/ubuntu/+source/dotnet6/+bug/2023531/comments/1
- Processes spawned?
- Yes, it is mainly in the `src/runtime` directory which is responsible
for dotnet runtime infrastructure. Most of the process spawn
instructions are found in `coreclr` which is the execution engine for
dotnet applications. It includes the JIT compiler, garbage collector,
and other low-level components that manage the execution of dotnet code.
- It also exists in many test files in `fsharp` directory, which is
expected
- Memory management?
- Heavy usage of memory-related functions in `runtime` directory, is
expected from a framework
- File IO?
- File IO operations are heavily used in `src/aspnetcore` and
`src/runtime` dirs
- Specifically, it is being used in the `src/runtime/src/libraries` directory
which provides fundamental functionality for .NET applications, such
as data types, collections, input/output, and more.
- This looks okay
- Logging?
- Error format looks fine
- It majorly uses `Trace.TraceError()`, `std::system_error()` and
`std::runtime_error()` in various situations, which is expected
- Environment variable usage?
- Env variables use in `src/runtime/src/mono/mono/eventpipe` dir look
fine. EventPipe is a feature that collects diagnostic and
telemetry information from dotnet applications at runtime. It's used
for profiling, debugging, and monitoring application behaviour.
- Other heavy usages of environment variables are in `eglib` dir. Embedded
GLib(eglib) is a low-level library that provides data structures, utilities,
and other core functionality for building applications on Linux.
- Env variables are being used safely.
- Use of privileged functions?
- It is very much used in `System.Native` dir, it likely contains the
implementation of native interop and low-level access to various native
system APIs and features on Unix-like platforms.
- This usage is expected.
- Use of cryptography / random number sources etc?
- `aspnetcore/src/Servers` dir is for web IIS server and it is
responsible for checking certificate chains as well. Looks fine
- Cryptographic functions used in `System.Security.Cryptography.Native`
component enables managed dotnet code to call the cryptographic
functions provided by the operating system's native libraries.
- This looks okay
- Use of temp files?
- Looks fine.
- Use of networking?
- Seems fine, `aspnetcore` dir has many occurrences of network socket
communication, which is expected considering its functionality.
- Use of WebKit/PolyKit?
- none
- Any significant cppcheck results?
- Majority of them are in tests directories. Issues regarding
`unknownMacro` and `syntaxError` are false positives.
- There are few issues on `integer overflow` and `null pointer dereference`
which are outlined in the files for s390x and riscv archs.
- Any significant Coverity results?
- version information disclosure is not an issue
- Hardcoded secrets in xml files are false-positve
- Majority of the issues are in test files which can be ignored
- Looks okay
- Any significant shellcheck results?
- looks fine
- Any significant bandit results?
- parse untrusted XML data in various files.
Microsoft has weekly meetings with their .NET Security Partners (including
Canonical) where updates and any new security issues are discussed.
Canonical receives embargoed access to the details for security issues as
well as early access to new dotnet releases that address the issues in
order to build, test, and overall prepare for a coordinated disclosure and
release on Patch Tuesday. Microsoft is additionally available outside the
scheduled meetings for any questions the Ubuntu Security or Foundations
Team may have regarding new releases.
I skimmed through the source code, which is well-written with proper comments
and documentation. Upstream is quite active in development as well.
After the MIR Team's requirements have been fulfilled to their satisfaction,
the Security team ACK for promoting dotnet6 to main.
I reviewed dotnet6 6.0.120 as checked into Mantic. This shouldn't be
considered a full audit but rather a quick gauge of maintainability.
dotnet6 is an open-source platform for building desktop, web, and mobile
applications that can run natively on any operating system. The dotnet
system includes tools, libraries, and languages that support modern,
scalable, and high-performance software development.
- CVE History: sdk-6.0- source- built-artifacts runtime- 6.0, dotnet- templates- 6.0, dotnet-sdk-6.0, targeting- pack-6. 0, netstandard- targeting- pack-2. 1, targeting- pack-6. 0, dotnet- apphost- pack-6. 0 /bugs.launchpad .net/ubuntu/ +source/ dotnet6/ +bug/2023531/ comments/ 1
- CVE-2022-38013: Fixed in 6.0.109
- CVE-2022-41032: Fixed in 6.0.110
- CVE-2023-21538: Fixed in 6.0.113
- CVE-2023-24936: Fixed in 6.0.118
- CVE-2023-28260: Fixed in 6.0.116
- CVE-2023-29331: Fixed in 6.0.118
- CVE-2023-29337: Fixed in 6.0.118
- CVE-2023-32032: Fixed in 6.0.118
- CVE-2023-33128: Fixed in 6.0.118
- CVE-2023-33170: Fixed in 6.0.120
- Build-Depends?
- clang
- cmake
- bash-completion
- debhelper-compat (= 13)
- dotnet-sdk-6.0
- dotnet-
- git
- libicu-dev
- libkrb5-dev
- liblttng-ust-dev
- libssl-dev
- libunwind-dev
- lld
- llvm
- locales-all
- python3
- zlib1g-dev
- pre/post inst/rm scripts?
- None
- init scripts?
- None
- systemd units?
- None
- dbus services?
- None
- setuid binaries?
- no `suid` or `sgid` binaries
- binaries in PATH?
- dotnet6, dotnet-host, dotnet-hostfxr-6.0, dotnet-runtime-6.0,
aspnetcore-
dotnet-
aspnetcore-
- sudo fragments?
- None
- polkit files?
- None
- udev rules?
- None
- unit tests / autopkgtests?
- Yes, autopkgtests runs fine locally passing all the tests
- cron jobs?
- None
- Build logs:
- same lintian errors described in https:/
- Processes spawned? src/libraries` directory TraceError( )`, `std::system_ error() ` and :runtime_ error() ` in various situations, which is expected src/mono/ mono/eventpipe` dir look src/Servers` dir is for web IIS server and it is Security. Cryptography. Native`
- Yes, it is mainly in the `src/runtime` directory which is responsible
for dotnet runtime infrastructure. Most of the process spawn
instructions are found in `coreclr` which is the execution engine for
dotnet applications. It includes the JIT compiler, garbage collector,
and other low-level components that manage the execution of dotnet code.
- It also exists in many test files in `fsharp` directory, which is
expected
- Memory management?
- Heavy usage of memory-related functions in `runtime` directory, is
expected from a framework
- File IO?
- File IO operations are heavily used in `src/aspnetcore` and
`src/runtime` dirs
- Specifically, it is being used in the `src/runtime/
which provides fundamental functionality for .NET applications, such
as data types, collections, input/output, and more.
- This looks okay
- Logging?
- Error format looks fine
- It majorly uses `Trace.
`std:
- Environment variable usage?
- Env variables use in `src/runtime/
fine. EventPipe is a feature that collects diagnostic and
telemetry information from dotnet applications at runtime. It's used
for profiling, debugging, and monitoring application behaviour.
- Other heavy usages of environment variables are in `eglib` dir. Embedded
GLib(eglib) is a low-level library that provides data structures, utilities,
and other core functionality for building applications on Linux.
- Env variables are being used safely.
- Use of privileged functions?
- It is very much used in `System.Native` dir, it likely contains the
implementation of native interop and low-level access to various native
system APIs and features on Unix-like platforms.
- This usage is expected.
- Use of cryptography / random number sources etc?
- `aspnetcore/
responsible for checking certificate chains as well. Looks fine
- Cryptographic functions used in `System.
component enables managed dotnet code to call the cryptographic
functions provided by the operating system's native libraries.
- This looks okay
- Use of temp files?
- Looks fine.
- Use of networking?
- Seems fine, `aspnetcore` dir has many occurrences of network socket
communication, which is expected considering its functionality.
- Use of WebKit/PolyKit?
- none
- Any significant cppcheck results?
- Majority of them are in tests directories. Issues regarding
`unknownMacro` and `syntaxError` are false positives.
- There are few issues on `integer overflow` and `null pointer dereference`
which are outlined in the files for s390x and riscv archs.
- Any significant Coverity results?
- version information disclosure is not an issue
- Hardcoded secrets in xml files are false-positve
- Majority of the issues are in test files which can be ignored
- Looks okay
- Any significant shellcheck results?
- looks fine
- Any significant bandit results?
- parse untrusted XML data in various files.
Microsoft has weekly meetings with their .NET Security Partners (including
Canonical) where updates and any new security issues are discussed.
Canonical receives embargoed access to the details for security issues as
well as early access to new dotnet releases that address the issues in
order to build, test, and overall prepare for a coordinated disclosure and
release on Patch Tuesday. Microsoft is additionally available outside the
scheduled meetings for any questions the Ubuntu Security or Foundations
Team may have regarding new releases.
I skimmed through the source code, which is well-written with proper comments
and documentation. Upstream is quite active in development as well.
After the MIR Team's requirements have been fulfilled to their satisfaction,
the Security team ACK for promoting dotnet6 to main.