mastouille.fr est l'un des nombreux serveurs Mastodon indépendants que vous pouvez utiliser pour participer au fédiverse.
Mastouille est une instance Mastodon durable, ouverte, et hébergée en France.

Administré par :

Statistiques du serveur :

592
comptes actifs

#staticanalysis

0 message0 participant0 message aujourd’hui

Как на счёт того, что на работу надо нанимать лишь профессионалов с должным уровнем знания языков программирования?
А не тех, кто считает, что этот код выведет −1.

#include <vector>
#include <numeric>
#include <iostream>

int average(const std::vector<int>& v) {
    if (v.empty()) {
        return 0;
    }
    return std::accumulate(v.begin(), v.end(), 0) / v.size();
}

int main() {
    std::cout << average({-1,-1,-1});
}
Если не верится, то https://godbolt.org/ в помощь.
Будучи собрано GCC или Clang для систем x86-64 оно выведет: 1431655764.

Ирония постиронией, а вот не смешно ни разу, поскольку никакой Clang-Tidy такого «не ловит»
bugprone-narrowing-conversions.
(извиняюсь за Керниган-Ричччи си-шный стиль в расстановке фигурных скобок, но так компактнее).

#программирование #C++ #С++ #Cpp #programming #softdev #staticanalysis #ClangTidy @russian_mastodon@mastodon.social @Russia@3zi.ru
godbolt.orgCompiler ExplorerCompiler Explorer is an interactive online compiler which shows the assembly output of compiled C++, Rust, Go (and many more) code.

Dylint - Run #Rust lints from dynamic libraries:

github.com/trailofbits/dylint

"Dylint is a Rust linting tool, similar to Clippy. But whereas #Clippy runs a predetermined, static set of lints, Dylint runs #lints from user-specified, dynamic libraries. Thus, Dylint allows developers to maintain their own personal lint collections."

Looks like a really cool project!

GitHubGitHub - trailofbits/dylint: Run Rust lints from dynamic librariesRun Rust lints from dynamic libraries. Contribute to trailofbits/dylint development by creating an account on GitHub.

Why did the #curl #CVE202338545 vulnerability hide from static analysis tools?

The main reason for this is the type of code structure in question. In general state engines are quite difficult for static analysis tools, since as the name implies the state of the various variables depend on runtime state changes.

The code attempts to determine whether it is safe to use the provided host name for remote resolution. Since the code does not function correctly with host names longer than 255 characters, it falls back to using “socks5://” protocol (local name resolution) if the host name is longer. When the name is too long, the code forces “local name resolution” by setting “socks5_resolve_local” variable to TRUE.

Unfortunately this “socks5_resolve_local” variable isn’t stored in the “socks_state” structure as it should have been. For each state “step” the initial value for the variable is determined with:

bool socks5_resolve_local =
(conn->socks_proxy.proxytype == CURLPROXY_SOCKS5) ? TRUE : FALSE;

The INIT state then set the “socks5_resolve_local” to TRUE if the host name is too long:

/* RFC1928 chapter 5 specifies max 255 chars for domain name in packet */
if(!socks5_resolve_local && hostname_len > 255) {
infof(data, "SOCKS5: server resolving disabled for hostnames of "
"length > 255 [actual len=%zu]", hostname_len);
socks5_resolve_local = TRUE;
}

But this check is *only* done in INIT state. When the state is anything else, the initial value is used.

Now, later CONNECT_RESOLVE_REMOTE state checks if remote name resolution should be used or not:

if(!socks5_resolve_local) {
if (… sx->hostname is literal IPv6 address …) {
… use ipv6 address direct …
}
else if (… sx->hostname is literal IPv4 address …) {
… use ipv4 address direct …
}
else {
socksreq[len++] = 3;
socksreq[len++] = (char) hostname_len; /* one byte address length */
memcpy(&socksreq[len], sx->hostname, hostname_len); /* w/o NULL */
len += hostname_len;
}
}
As “socks5_resolve_local” flag is FALSE for the excessively long hostname the “socksreq” heap buffer will be overflown by the memcpy call.

There is no obvious way for the static analysis tools to determine that “socks5_resolve_local” might be set incorrectly for some of the states. Runtime #fuzzing will find this flaw quite easily, but unfortunately no fuzzing was performed for this specific functionality.