Statically typed error handling PoC

[Tehforsch]

This is a proposal for revamped error type structure and handling for NASL builtin functions as well as some minor changes to error handling in general.

Error type structure

The main type this refactoring is concerned with is FunctionErrorKind which has been renamed to FnError.

In this proposed new error structure, FnError is an actual type that contains metadata about the error (such as whether the error can be solved by retrying the operation that caused it and the return value given to the NASL caller), as well as its kind, described by the FnErrorKind enum. This enum corresponds to the previous FunctionErrorKind and is structured as follows:

pub enum FnErrorKind {
    Argument(ArgumentError),
    Internal(InternalError),
    Builtin(BuiltinError),
}

The variants represent three different kinds of errors: ArgumentError refers to errors caused by calling a function with the wrong arguments which typically reflect an error in the usage of the function by the script authors.

InternalError refers to any error caused by failure of an internal process of the scanner (such as the storage). This reflects a deeper problem and may mean we cannot simply proceed with execution of the scan.

Finally, BuiltinError represents any (more or less expected) error that occurred within a builtin function. This may include timeouts, authentication failures, etc..

Error handling

I think the exact rules for how we treat each error type are something that is still open to discussion, but I'll write down the rules for the implementation in this PR as a basis for this discussion.

As stated above, the metadata (return value, retryable) on how to handle a specific error are stored in a FnError (as opposed to deriving them by matching on the kind of the error). This means that in principle, we always have the option of explicitly overriding any defaults for any specific case. However, I hope that we rarely need this in practice because we can choose sane defaults that reflect what we want most of the time.

Return behavior

The return behavior of a given error specifies how an error should be handled during execution. This is specified by the following type:

enum ReturnBehavior {
    ExitScript,
    ReturnValue(NaslValue),
}

This type is equivalent to Option<NaslValue> but we decided that having a custom type here would make the intent clearer.
When the interpreter encounters an error with ReturnBehavior::ExitScript behavior, it will unsurprisingly exit the script. If it encounters an error with ReturnBehavior::ReturnValue(val), it will return val and continue execution. This behavior is effectively equivalent to the Diagnostic variant of FunctionErrorKind.

The Argument and Internal variants of FnError are automatically constructed with ReturnBehavior::ExitScript, meaning that they abort execution of the script. The Builtin variant is constructed with ReturnBehavior::ReturnValue(NaslValue::Null) by default, but this value can easily be overwritten when the error is created, for example:

HttpError::HandleIdNotFound(handle).with(ReturnValue(-1))

Retry behavior

Certain errors can be flagged as being solvable by retrying the operation that caused them. This is represented by a retryable boolean on FnError, which is false by default for all variants except for a specific internal error in the storage. However, this default behavior can be overwritten at error creation if needed, for example

HttpError::ConnectionFailed(...).with(Retryable)

I also added a small test to make sure that the interpreter does actually retry retryable errors.

Boilerplate / Cost

Since this was the main point of the discussion on implementation strategies for these errors, I figured I'd write down the amount of additional overhead for creating these custom error types that is currently needed when a new builtin module is created.

1. Add a custom error type for the builtin module. These can be of arbitrary form but a typical error type might look like

#[derive(Debug, Error)]
enum FooError {
    #[error("Bar occurred.")]
    Bar,
    #[error("Baz occurred. Here is some more data: {0}")]
    Baz(SomeData),
}

I personally like this approach anyways since it keeps error messages all in one place and makes it easy to get an overview of all the error messages and to keep them consistent.

2. Add this builtin error as a variant of the BuiltinError type described above. This is one line of code:

enum BuiltinError {
    ...
    Foo(FooError),
    ...
}

3. For convenience, some From impls and TryFrom impls can make the error type easier to use by enabling use of the question mark operator. I added a tiny macro that implements these traits (because the implementations are usually trivial), so this comes down to one line too:
   builtin_error_variant!(Foo, FooError);

This is all that is needed to make this error usable in NASL functions:

fn check(a: usize) -> Result<(), FooError> {
    if a == 0 {
        Err(FooError::Bar)
    }
    else { 
        Ok(())
    }
}

#[nasl_function]
fn foo(a: usize) -> Result<usize, FnError> {
    check(a)?;
    Ok(a)
}

As a side note, NASL functions can also return any concrete impl Into<FnError> directly, so for this case we can also write

#[nasl_function]
fn foo(a: usize) -> Result<usize, FooError> {
    if a == 0 { 
        Err(FooError::Bar)
    }
    else {
        Ok(a)
    }
}

Note that the above From impls that are automatically written by the builtin_error_variant! macro can also be manually implemented if one wants to specify defaults for a specific error variant. For example

impl From<FooError> for FnError {
    fn from(e: FooError) -> FnError {
        match e {
            FooError::Foo => BuiltinError::Foo(e).with(ReturnValue(-1)),
            _ => BuiltinError::Foo(e).into(),
        }
    }
}

PartialEq, Eq and Clone

Previously, all our error types derived PartialEq, Eq, Clone. This was basically unused in the codebase (with some minor exceptions where an easy rewrite made these derives unnecessary). In this PR I got rid of all of these derives. This has the advantage of making it easier to wrap certain internal library errors that may not implement any of the three traits (std::io::Error implements neither and is used quite a bit, for example, causing us to always use the io::ErrorKind instead.). I think there is a case to be made for either choice, but personally prefer not implementing these.
Note that this will also be a problem in a dyn FnError-based solution, since the type will have to become dyn FnError + PartialEq + Eq + Clone or alternatively FnError will have to be defined as trait FnError: PartialEq + Eq + Clone, either requiring each concrete type to implement the three traits.

WithErrorInfo

As a last, opinionated part of this PR, I added a trait WithErrorInfo that is basically meant to attach some kind of information to an already existing error. This originated in the SSH implementation, where I wanted to add the SessionId that caused the error to ~70% of error variants (but not all of them, which would have meant I could simply make it part of the parent error). I also often wanted to add the internal library error that caused the error to occur. This trait made it convenient to simply write SshError::Foo.with(session_id).with(err). I then stumbled upon this concept again when I wanted to attach the retryable/return behavior information discussed above to certain errors, so I simply extended this trait to allow usage like .with(ReturnValue(-1)) or .with(Retryable) where ReturnValue and Retryable are simply dummy types meant for just this one purpose. This has the nice advantage of allowing autoconversion to FnError making the resulting code look really clean, but if this is too fancy I'm fine with getting rid of it. An alternative would be to implement methods like with_return_value and .with_retryable for every type that needs them or to instead write FnError::from(...).with_retryable() which is more verbose.

Todo

• Write documentation on how to do error handling now, i.e. the steps to take when writing new builtin functions, general guidelines, as well as the meaning of the individual error variants. Ideally in a .md document somewhere in the crate.
• Open tickets for parts of the code where error handling doesn't follow these guidelines
• Get rid of two unnecessary constructors FnError / ArgumentError

[github-actions]

Dependency Review

✅ No vulnerabilities or license issues or OpenSSF Scorecard issues found.

Snapshot Warnings

⚠️: No snapshots were found for the head SHA 0f63731.

Ensure that dependencies are being submitted on PR branches and consider enabling retry-on-snapshot-warnings. See the documentation for more information and troubleshooting advice.

OpenSSF Scorecard

Package	Version	Score	Details

Scanned Files

[github-actions]

🔍 Vulnerabilities of harbor-os.greenbone.net/community/openvas-scanner:1752-merge-amd64

📦 Image Reference harbor-os.greenbone.net/community/openvas-scanner:1752-merge-amd64

digest	sha256:778ea26c17a02b0be712ade60fea9d986042f7e823ea9e791441017656fcf091
vulnerabilities
size	142 MB
packages	262

📦 Base Image debian:stable-20241111-slim

also known as	stable-slim
digest	sha256:4821d386c4d96ba06dbaa992f225af5b7aa6d5cc400dfbf993df44526bb843d0
vulnerabilities

glibc 2.36-9+deb12u9 (deb) pkg:deb/debian/glibc@2.36-9%2Bdeb12u9?os_distro=bookworm&os_name=debian&os_version=12 Affected range >=2.36-9+deb12u9 Fixed version Not Fixed EPSS Score 0.11% EPSS Percentile 45th percentile Description In the GNU C Library (aka glibc or libc6) through 2.29, check_dst_limits_calc_pos_1 in posix/regexec.c has Uncontrolled Recursion, as demonstrated by '(|)(\1\1)*' in grep, a different issue than CVE-2018-20796. NOTE: the software maintainer disputes that this is a vulnerability because the behavior occurs only with a crafted pattern Affected range >=2.36-9+deb12u9 Fixed version Not Fixed EPSS Score 0.35% EPSS Percentile 73rd percentile Description GNU Libc current is affected by: Mitigation bypass. The impact is: Attacker may guess the heap addresses of pthread_created thread. The component is: glibc. NOTE: the vendor's position is "ASLR bypass itself is not a vulnerability. Affected range >=2.36-9+deb12u9 Fixed version Not Fixed EPSS Score 3.02% EPSS Percentile 91st percentile Description GNU Libc current is affected by: Mitigation bypass. The impact is: Attacker may bypass ASLR using cache of thread stack and heap. The component is: glibc. NOTE: Upstream comments indicate "this is being treated as a non-security bug and no real threat. Affected range >=2.36-9+deb12u9 Fixed version Not Fixed EPSS Score 1.20% EPSS Percentile 86th percentile Description GNU Libc current is affected by: Re-mapping current loaded library with malicious ELF file. The impact is: In worst case attacker may evaluate privileges. The component is: libld. The attack vector is: Attacker sends 2 ELF files to victim and asks to run ldd on it. ldd execute code. NOTE: Upstream comments indicate "this is being treated as a non-security bug and no real threat. Affected range >=2.36-9+deb12u9 Fixed version Not Fixed EPSS Score 0.41% EPSS Percentile 75th percentile Description GNU Libc current is affected by: Mitigation bypass. The impact is: Attacker may bypass stack guard protection. The component is: nptl. The attack vector is: Exploit stack buffer overflow vulnerability and use this bypass vulnerability to bypass stack guard. NOTE: Upstream comments indicate "this is being treated as a non-security bug and no real threat. Affected range >=2.36-9+deb12u9 Fixed version Not Fixed EPSS Score 0.44% EPSS Percentile 76th percentile Description In the GNU C Library (aka glibc or libc6) through 2.29, check_dst_limits_calc_pos_1 in posix/regexec.c has Uncontrolled Recursion, as demonstrated by '(\227|)(\1\1|t1|\\2537)+' in grep. Affected range >=2.36-9+deb12u9 Fixed version Not Fixed EPSS Score 0.82% EPSS Percentile 83rd percentile Description The glob implementation in the GNU C Library (aka glibc or libc6) allows remote authenticated users to cause a denial of service (CPU and memory consumption) via crafted glob expressions that do not match any pathnames, as demonstrated by glob expressions in STAT commands to an FTP daemon, a different vulnerability than CVE-2010-2632.

pcre3 2:8.39-15 (deb) pkg:deb/debian/pcre3@2:8.39-15?os_distro=bookworm&os_name=debian&os_version=12 Affected range >=2:8.39-15 Fixed version Not Fixed EPSS Score 0.98% EPSS Percentile 84th percentile Description libpcre in PCRE before 8.43 allows a subject buffer over-read in JIT when UTF is disabled, and \X or \R has more than one fixed quantifier, a related issue to CVE-2019-20454. Affected range >=2:8.39-15 Fixed version Not Fixed EPSS Score 0.65% EPSS Percentile 80th percentile Description Stack-based buffer overflow in the pcre32_copy_substring function in pcre_get.c in libpcre1 in PCRE 8.40 allows remote attackers to cause a denial of service (WRITE of size 268) or possibly have unspecified other impact via a crafted file. Affected range >=2:8.39-15 Fixed version Not Fixed EPSS Score 0.65% EPSS Percentile 80th percentile Description Stack-based buffer overflow in the pcre32_copy_substring function in pcre_get.c in libpcre1 in PCRE 8.40 allows remote attackers to cause a denial of service (WRITE of size 4) or possibly have unspecified other impact via a crafted file. Affected range >=2:8.39-15 Fixed version Not Fixed EPSS Score 0.08% EPSS Percentile 37th percentile Description In PCRE 8.41, after compiling, a pcretest load test PoC produces a crash overflow in the function match() in pcre_exec.c because of a self-recursive call. NOTE: third parties dispute the relevance of this report, noting that there are options that can be used to limit the amount of stack that is used Affected range >=2:8.39-15 Fixed version Not Fixed EPSS Score 0.37% EPSS Percentile 73rd percentile Description In PCRE 8.41, the OP_KETRMAX feature in the match function in pcre_exec.c allows stack exhaustion (uncontrolled recursion) when processing a crafted regular expression.

openldap 2.5.13+dfsg-5 (deb) pkg:deb/debian/openldap@2.5.13%2Bdfsg-5?os_distro=bookworm&os_name=debian&os_version=12 Affected range >=2.5.13+dfsg-5 Fixed version Not Fixed EPSS Score 0.16% EPSS Percentile 54th percentile Description libldap in certain third-party OpenLDAP packages has a certificate-validation flaw when the third-party package is asserting RFC6125 support. It considers CN even when there is a non-matching subjectAltName (SAN). This is fixed in, for example, openldap-2.4.46-10.el8 in Red Hat Enterprise Linux. Affected range >=2.5.13+dfsg-5 Fixed version Not Fixed EPSS Score 0.41% EPSS Percentile 75th percentile Description contrib/slapd-modules/nops/nops.c in OpenLDAP through 2.4.45, when both the nops module and the memberof overlay are enabled, attempts to free a buffer that was allocated on the stack, which allows remote attackers to cause a denial of service (slapd crash) via a member MODDN operation. Affected range >=2.5.13+dfsg-5 Fixed version Not Fixed EPSS Score 0.04% EPSS Percentile 11th percentile Description slapd in OpenLDAP 2.4.45 and earlier creates a PID file after dropping privileges to a non-root account, which might allow local users to kill arbitrary processes by leveraging access to this non-root account for PID file modification before a root script executes a "kill cat /pathname" command, as demonstrated by openldap-initscript. Affected range >=2.5.13+dfsg-5 Fixed version Not Fixed EPSS Score 0.42% EPSS Percentile 75th percentile Description The nss_parse_ciphers function in libraries/libldap/tls_m.c in OpenLDAP does not properly parse OpenSSL-style multi-keyword mode cipher strings, which might cause a weaker than intended cipher to be used and allow remote attackers to have unspecified impact via unknown vectors.

systemd 252.31-1~deb12u1 (deb) pkg:deb/debian/systemd@252.31-1~deb12u1?os_distro=bookworm&os_name=debian&os_version=12 Affected range >=252.31-1~deb12u1 Fixed version Not Fixed EPSS Score 0.11% EPSS Percentile 45th percentile Description An issue was discovered in systemd 253. An attacker can modify the contents of past events in a sealed log file and then adjust the file such that checking the integrity shows no error, despite modifications. NOTE: the vendor reportedly sent "a reply denying that any of the finding was a security vulnerability." Affected range >=252.31-1~deb12u1 Fixed version Not Fixed EPSS Score 0.11% EPSS Percentile 45th percentile Description An issue was discovered in systemd 253. An attacker can truncate a sealed log file and then resume log sealing such that checking the integrity shows no error, despite modifications. NOTE: the vendor reportedly sent "a reply denying that any of the finding was a security vulnerability." Affected range >=252.31-1~deb12u1 Fixed version Not Fixed EPSS Score 0.10% EPSS Percentile 42nd percentile Description An issue was discovered in systemd 253. An attacker can modify a sealed log file such that, in some views, not all existing and sealed log messages are displayed. NOTE: the vendor reportedly sent "a reply denying that any of the finding was a security vulnerability." Affected range >=252.31-1~deb12u1 Fixed version Not Fixed EPSS Score 0.04% EPSS Percentile 5th percentile Description systemd, when updating file permissions, allows local users to change the permissions and SELinux security contexts for arbitrary files via a symlink attack on unspecified files.

krb5 1.20.1-2+deb12u2 (deb) pkg:deb/debian/krb5@1.20.1-2%2Bdeb12u2?os_distro=bookworm&os_name=debian&os_version=12 Affected range >=1.20.1-2+deb12u2 Fixed version Not Fixed EPSS Score 0.04% EPSS Percentile 10th percentile Description Kerberos 5 (aka krb5) 1.21.2 contains a memory leak vulnerability in /krb5/src/lib/gssapi/krb5/k5sealv3.c. Affected range >=1.20.1-2+deb12u2 Fixed version Not Fixed EPSS Score 0.04% EPSS Percentile 10th percentile Description Kerberos 5 (aka krb5) 1.21.2 contains a memory leak in /krb5/src/lib/rpc/pmap_rmt.c. Affected range >=1.20.1-2+deb12u2 Fixed version Not Fixed EPSS Score 0.10% EPSS Percentile 42nd percentile Description An issue was discovered in MIT Kerberos 5 (aka krb5) through 1.16. There is a variable "dbentry->n_key_data" in kadmin/dbutil/dump.c that can store 16-bit data but unknowingly the developer has assigned a "u4" variable to it, which is for 32-bit data. An attacker can use this vulnerability to affect other artifacts of the database as we know that a Kerberos database dump file contains trusted data.

perl 5.36.0-7+deb12u1 (deb) pkg:deb/debian/perl@5.36.0-7%2Bdeb12u1?os_distro=bookworm&os_name=debian&os_version=12 Affected range >=5.36.0-7+deb12u1 Fixed version Not Fixed EPSS Score 0.23% EPSS Percentile 62nd percentile Description HTTP::Tiny before 0.083, a Perl core module since 5.13.9 and available standalone on CPAN, has an insecure default TLS configuration where users must opt in to verify certificates. Affected range >=5.36.0-7+deb12u1 Fixed version Not Fixed EPSS Score 0.24% EPSS Percentile 65th percentile Description _is_safe in the File::Temp module for Perl does not properly handle symlinks.

m4 1.4.19-3 (deb) pkg:deb/debian/m4@1.4.19-3?os_distro=bookworm&os_name=debian&os_version=12 Affected range >=1.4.19-3 Fixed version Not Fixed EPSS Score 2.99% EPSS Percentile 91st percentile Description Unspecified vulnerability in GNU m4 before 1.4.11 might allow context-dependent attackers to execute arbitrary code, related to improper handling of filenames specified with the -F option. NOTE: it is not clear when this issue crosses privilege boundaries. Affected range >=1.4.19-3 Fixed version Not Fixed EPSS Score 2.12% EPSS Percentile 90th percentile Description The (1) maketemp and (2) mkstemp builtin functions in GNU m4 before 1.4.11 do not quote their output when a file is created, which might allow context-dependent attackers to trigger a macro expansion, leading to unspecified use of an incorrect filename.

gcc-12 12.2.0-14 (deb) pkg:deb/debian/gcc-12@12.2.0-14?os_distro=bookworm&os_name=debian&os_version=12 Affected range >=12.2.0-14 Fixed version Not Fixed EPSS Score 0.06% EPSS Percentile 26th percentile Description DISPUTEDA failure in the -fstack-protector feature in GCC-based toolchains that target AArch64 allows an attacker to exploit an existing buffer overflow in dynamically-sized local variables in your application without this being detected. This stack-protector failure only applies to C99-style dynamically-sized local variables or those created using alloca(). The stack-protector operates as intended for statically-sized local variables. The default behavior when the stack-protector detects an overflow is to terminate your application, resulting in controlled loss of availability. An attacker who can exploit a buffer overflow without triggering the stack-protector might be able to change program flow control to cause an uncontrolled loss of availability or to go further and affect confidentiality or integrity. NOTE: The GCC project argues that this is a missed hardening bug and not a vulnerability by itself. Affected range >=12.2.0-14 Fixed version Not Fixed EPSS Score 0.09% EPSS Percentile 39th percentile Description libiberty/rust-demangle.c in GNU GCC 11.2 allows stack consumption in demangle_const, as demonstrated by nm-new.

libpcap 1.10.3-1 (deb) pkg:deb/debian/libpcap@1.10.3-1?os_distro=bookworm&os_name=debian&os_version=12 Affected range >=1.10.3-1 Fixed version Not Fixed EPSS Score 0.04% EPSS Percentile 10th percentile Description Remote packet capture support is disabled by default in libpcap. When a user builds libpcap with remote packet capture support enabled, one of the functions that become available is pcap_findalldevs_ex(). One of the function arguments can be a filesystem path, which normally means a directory with input data files. When the specified path cannot be used as a directory, the function receives NULL from opendir(), but does not check the return value and passes the NULL value to readdir(), which causes a NULL pointer derefence. Affected range >=1.10.3-1 Fixed version Not Fixed EPSS Score 0.04% EPSS Percentile 10th percentile Description In affected libpcap versions during the setup of a remote packet capture the internal function sock_initaddress() calls getaddrinfo() and possibly freeaddrinfo(), but does not clearly indicate to the caller function whether freeaddrinfo() still remains to be called after the function returns. This makes it possible in some scenarios that both the function and its caller call freeaddrinfo() for the same allocated memory block. A similar problem was reported in Apple libpcap, to which Apple assigned CVE-2023-40400.

gnutls28 3.7.9-2+deb12u3 (deb) pkg:deb/debian/gnutls28@3.7.9-2%2Bdeb12u3?os_distro=bookworm&os_name=debian&os_version=12 Affected range >=3.7.9-2+deb12u3 Fixed version Not Fixed EPSS Score 0.60% EPSS Percentile 79th percentile Description The SSL protocol, as used in certain configurations in Microsoft Windows and Microsoft Internet Explorer, Mozilla Firefox, Google Chrome, Opera, and other products, encrypts data by using CBC mode with chained initialization vectors, which allows man-in-the-middle attackers to obtain plaintext HTTP headers via a blockwise chosen-boundary attack (BCBA) on an HTTPS session, in conjunction with JavaScript code that uses (1) the HTML5 WebSocket API, (2) the Java URLConnection API, or (3) the Silverlight WebClient API, aka a "BEAST" attack.

glib2.0 2.74.6-2+deb12u4 (deb) pkg:deb/debian/glib2.0@2.74.6-2%2Bdeb12u4?os_distro=bookworm&os_name=debian&os_version=12 Affected range >=2.74.6-2+deb12u4 Fixed version Not Fixed EPSS Score 0.16% EPSS Percentile 53rd percentile Description GLib 2.31.8 and earlier, when the g_str_hash function is used, computes hash values without restricting the ability to trigger hash collisions predictably, which allows context-dependent attackers to cause a denial of service (CPU consumption) via crafted input to an application that maintains a hash table. NOTE: this issue may be disputed by the vendor; the existence of the g_str_hash function is not a vulnerability in the library, because callers of g_hash_table_new and g_hash_table_new_full can specify an arbitrary hash function that is appropriate for the application.

coreutils 9.1-1 (deb) pkg:deb/debian/coreutils@9.1-1?os_distro=bookworm&os_name=debian&os_version=12 Affected range >=9.1-1 Fixed version Not Fixed EPSS Score 0.04% EPSS Percentile 5th percentile Description In GNU Coreutils through 8.29, chown-core.c in chown and chgrp does not prevent replacement of a plain file with a symlink during use of the POSIX "-R -L" options, which allows local users to modify the ownership of arbitrary files by leveraging a race condition.

shadow 1:4.13+dfsg1-1 (deb) pkg:deb/debian/shadow@1:4.13%2Bdfsg1-1?os_distro=bookworm&os_name=debian&os_version=12 Affected range >=1:4.13+dfsg1-1 Fixed version Not Fixed EPSS Score 0.16% EPSS Percentile 53rd percentile Description initscripts in rPath Linux 1 sets insecure permissions for the /var/log/btmp file, which allows local users to obtain sensitive information regarding authentication attempts. NOTE: because sshd detects the insecure permissions and does not log certain events, this also prevents sshd from logging failed authentication attempts by remote attackers.

tar 1.34+dfsg-1.2+deb12u1 (deb) pkg:deb/debian/tar@1.34%2Bdfsg-1.2%2Bdeb12u1?os_distro=bookworm&os_name=debian&os_version=12 Affected range >=1.34+dfsg-1.2+deb12u1 Fixed version Not Fixed EPSS Score 0.69% EPSS Percentile 81st percentile Description Tar 1.15.1 does not properly warn the user when extracting setuid or setgid files, which may allow local users or remote attackers to gain privileges.

libxml2 2.9.14+dfsg-1.3~deb12u1 (deb) pkg:deb/debian/libxml2@2.9.14%2Bdfsg-1.3~deb12u1?os_distro=bookworm&os_name=debian&os_version=12 Affected range >=2.9.14+dfsg-1.3~deb12u1 Fixed version Not Fixed EPSS Score 0.04% EPSS Percentile 12th percentile Description An issue was discovered in xmllint (from libxml2) before 2.11.8 and 2.12.x before 2.12.7. Formatting error messages with xmllint --htmlout can result in a buffer over-read in xmlHTMLPrintFileContext in xmllint.c.

curl 7.88.1-10+deb12u8 (deb) pkg:deb/debian/curl@7.88.1-10%2Bdeb12u8?os_distro=bookworm&os_name=debian&os_version=12 Affected range >=7.88.1-10+deb12u8 Fixed version Not Fixed EPSS Score 0.04% EPSS Percentile 15th percentile Description libcurl skips the certificate verification for a QUIC connection under certain conditions, when built to use wolfSSL. If told to use an unknown/bad cipher or curve, the error path accidentally skips the verification and returns OK, thus ignoring any certificate problems.

apt 2.6.1 (deb) pkg:deb/debian/apt@2.6.1?os_distro=bookworm&os_name=debian&os_version=12 Affected range >=2.6.1 Fixed version Not Fixed EPSS Score 0.17% EPSS Percentile 54th percentile Description It was found that apt-key in apt, all versions, do not correctly validate gpg keys with the master keyring, leading to a potential man-in-the-middle attack.

gnupg2 2.2.40-1.1 (deb) pkg:deb/debian/gnupg2@2.2.40-1.1?os_distro=bookworm&os_name=debian&os_version=12 Affected range >=2.2.40-1.1 Fixed version Not Fixed EPSS Score 0.05% EPSS Percentile 19th percentile Description GnuPG can be made to spin on a relatively small input by (for example) crafting a public key with thousands of signatures attached, compressed down to just a few KB.

openssl 3.0.15-1~deb12u1 (deb) pkg:deb/debian/openssl@3.0.15-1~deb12u1?os_distro=bookworm&os_name=debian&os_version=12 Affected range >=3.0.11-1~deb12u2 Fixed version Not Fixed EPSS Score 0.07% EPSS Percentile 31st percentile Description OpenSSL 0.9.8i on the Gaisler Research LEON3 SoC on the Xilinx Virtex-II Pro FPGA uses a Fixed Width Exponentiation (FWE) algorithm for certain signature calculations, and does not verify the signature before providing it to a caller, which makes it easier for physically proximate attackers to determine the private key via a modified supply voltage for the microprocessor, related to a "fault-based attack."

sqlite3 3.40.1-2+deb12u1 (deb) pkg:deb/debian/sqlite3@3.40.1-2%2Bdeb12u1?os_distro=bookworm&os_name=debian&os_version=12 Affected range >=3.40.1-2+deb12u1 Fixed version Not Fixed EPSS Score 0.22% EPSS Percentile 61st percentile Description A Memory Leak vulnerability exists in SQLite Project SQLite3 3.35.1 and 3.37.0 via maliciously crafted SQL Queries (made via editing the Database File), it is possible to query a record, and leak subsequent bytes of memory that extend beyond the record, which could let a malicious user obtain sensitive information. NOTE: The developer disputes this as a vulnerability stating that If you give SQLite a corrupted database file and submit a query against the database, it might read parts of the database that you did not intend or expect.

libgcrypt20 1.10.1-3 (deb) pkg:deb/debian/libgcrypt20@1.10.1-3?os_distro=bookworm&os_name=debian&os_version=12 Affected range >=1.10.1-3 Fixed version Not Fixed EPSS Score 0.19% EPSS Percentile 58th percentile Description cipher/elgamal.c in Libgcrypt through 1.8.2, when used to encrypt messages directly, improperly encodes plaintexts, which allows attackers to obtain sensitive information by reading ciphertext data (i.e., it does not have semantic security in face of a ciphertext-only attack). The Decisional Diffie-Hellman (DDH) assumption does not hold for Libgcrypt's ElGamal implementation.

nmap 7.93+dfsg1-1 (deb) pkg:deb/debian/nmap@7.93%2Bdfsg1-1?os_distro=bookworm&os_name=debian&os_version=12 Affected range >=7.93+dfsg1-1 Fixed version Not Fixed EPSS Score 2.28% EPSS Percentile 90th percentile Description Nmap through 7.70, when the -sV option is used, allows remote attackers to cause a denial of service (stack consumption and application crash) via a crafted TCP-based service.

net-tools 2.10-0.1 (deb) pkg:deb/debian/net-tools@2.10-0.1?os_distro=bookworm&os_name=debian&os_version=12 Affected range >=2.10-0.1 Fixed version Not Fixed EPSS Score 0.06% EPSS Percentile 26th percentile Description ifconfig, when used on the Linux kernel 2.2 and later, does not report when the network interface is in promiscuous mode if it was put in promiscuous mode using PACKET_MR_PROMISC, which could allow attackers to sniff the network without detection, as demonstrated using libpcap.

util-linux 2.38.1-5+deb12u2 (deb) pkg:deb/debian/util-linux@2.38.1-5%2Bdeb12u2?os_distro=bookworm&os_name=debian&os_version=12 Affected range >=2.38.1-5+deb12u2 Fixed version Not Fixed EPSS Score 0.05% EPSS Percentile 19th percentile Description A flaw was found in the util-linux chfn and chsh utilities when compiled with Readline support. The Readline library uses an "INPUTRC" environment variable to get a path to the library config file. When the library cannot parse the specified file, it prints an error message containing data from the file. This flaw allows an unprivileged user to read root-owned files, potentially leading to privilege escalation. This flaw affects util-linux versions prior to 2.37.4.

net-snmp 5.9.3+dfsg-2 (deb) pkg:deb/debian/net-snmp@5.9.3%2Bdfsg-2?os_distro=bookworm&os_name=debian&os_version=12 Affected range >=5.9.3+dfsg-2 Fixed version Not Fixed Description net-snmp 5.9.4 contains a memory leak vulnerability in /net-snmp/apps/snmpvacm.c.

[nichtsfrei]

Keep in mind that the io::ErrorKind is used to identify retry cases, see https://github.com/greenbone/openvas-scanner/blob/main/rust/src/nasl/interpreter/interpreter.rs#L196 for an incomplete example. The possibility to identify cases that can be retried transparently to the user should be considered.

[Tehforsch]

Keep in mind that the io::ErrorKind is used to identify retry cases, see https://github.com/greenbone/openvas-scanner/blob/main/rust/src/nasl/interpreter/interpreter.rs#L196 for an incomplete example. The possibility to identify cases that can be retried transparently to the user should be considered.

I think we need a more robust set up to identify these cases. Using IO errors to mean retryable might be a good heuristic, but is still not accurate, since there are both false positives (io::ErrorKind::NotADirectory is not something that will be solved by retrying) and false negatives (an ssh connection might fail due to a timeout but won't return an IO error).
I am not sure that we can find a high level structure that represents re-try-ability well and would prefer doing this on a "local" level, i.e. someting like

foo().map_err(|e| MyCustomError::MyCustomErrorVariant(e).retryable())`

(method naming very much up for debate)

[nichtsfrei]

Yes, it’s imperfect—I wasn’t suggesting we use it as-is. However, this concept is entirely missing from the current proposal, even though it’s available, albeit imperfectly, in the current handling.

I’m not in favor of implementing it at a local level because it relies too heavily on the function developer's knowledge and could lead to inconsistent handling, making it harder to reason about, inconvenient, and adding cognitive load—especially when you just want to quickly create a built-in function.

[Tehforsch]

Yes, it’s imperfect—I wasn’t suggesting we use it as-is. However, this concept is entirely missing from the current proposal, even though it’s available, albeit imperfectly, in the current handling.

Yes, youre right.

I’m not in favor of implementing it at a local level because it relies too heavily on the function developer's knowledge and could lead to inconsistent handling, making it harder to reason about, inconvenient, and adding cognitive load—especially when you just want to quickly create a built-in function.

I was also afraid of that, but if we don't trust the author of the builtin function to make the correct decision on whether an error is solvable by retrying or not, then I don't think we have a chance of solving this problem anyways. I would prefer doing this on a local level because it still gives us the room to discuss these things in code review etc.. I think making the overarching structure of the error type determine whether an error is "retryable" or not carries a larger risk because we will eventually have to fight our own system if we want more precise control over these errors.

This also doesn't always have to be solved on the most local level, because you could, for example, write an From impl for your error type such as

impl From<io::Error> for MyCustomError {
    fn from(val: io:Error) -> MyCustomError {
        MyCustomError::Foo(val).retryable()
    }
}

which effectively reproduces the original behavior of making any io::Error something that can be solved by retrying, but does it on a more fine-grained level (for an entire builtin module), where it might always make sense.