Daniel Shahaf wrote on Mon, Jan 17, 2022 at 14:59:15 +0000:
> Sam Ruby wrote on Mon, 17 Jan 2022 01:20 +00:00:
> > I would love to move everything currently on that page to be background
> > material or delete it entirely and start over if we can find a way to
> > address the questions I describe above. Heck the background material could
> > even go into how JNDI extends LDAP to cover Java Objects, and log4j allowed
> > (past tense) the data to be logged to point their queries at an attacker's
> > server who could respond not with the answer to the question posed but with
> > instructions on how to load their Java Object, and why that is a very bad
> > thing, and how you had to know about things like CORBA and RMI that were
> > popular 25 years ago to even figure this out.
>
> the log4j bug was ultimately down to string-typed data that
> contained both literal payloads and directives (like percent signs in
> printf(3), date(1), and crontab(5); e.g., «printf(argv[1])» is a common
> mistake, and compilers warn about it nowadays). Some of those
> directives could be used to execute code.
>
> Simplified: A string value was assigned [actually, passed as
> actual parameter] to string variable without being escaped/sanitized first.
>
> Simplified: There was a variable [= register, memory location] that held
> something's price in cents. Somebody stored in that variable the price
> in dollars without multiplying by 100 first (which, incidentally, is
> almost exactly
> <https://en.wikipedia.org/wiki/Mars_Climate_Orbiter#Cause_of_failure>).
>
> At which point, it's just a question of type safety. E.g., in C, using
> «struct in_dollars { int value; };» and «struct in_cents { int value; };»
> would address this. The idea would work for string types too.
>
> Net result: choosing a particular value for the ones and tens digits of
> the number of dollars could cause code determined by those two digits to
> be executed. And those two digits happened to be attacker-controlled.
A few more things about the specific vulnerability.
The vulnerability which began this rollercoaster ride, CVE-2021-44228,
was assigned by the Apache Logging Services PMC a CVSSv3 Base Score of
a perfect 10.0.
However, that's an optical illusion. When CVSSv3 is used as designed,
every deployment's administrators compute a CVSSv3 Environmental Score
for the vulnerability _in their deployment_. In the case of
CVE-2021-44228, the Environmental Score would typically be affected by
factors such as:
* The attacker might not be able to set the ones and tens digits to
any value, but only to particular ones.
(Why? Because of higher-layer validations. For instance, in an
in-browser sign-up form that logs the requested username, the logged
value would comprise letters, digits, underscores, and hyphens
only. In this situation, CVE-2021-44228 would be inexploitable.)
* Because even with full control over those two digits, one can't
execute _any_ code, in this case, but only code that makes
a particular network access. However, the deployment's egress
network access might be severely limited by so-called "default deny"
firewalls. That's a long-standing best practice (specifically,
an instance of POLP).
Implementing such firewalls is very easy. For instance,
.
block all
pass in from any to any port ssh
pass in from any to any port https
.
is a valid pf.conf(5) file implementing such a firewall.
This would make the vulnerability inexploitable in most cases.
(Why only "most" cases? Because pf(4) doesn't filter loopback
traffic by default, and in theory there could be an LDAP server on
localhost that contains attacker-controlled data. The likelihood
of this scenario is inversely proportional to its Kolmogorov
complexity.)
Extra reading: <https://man.openbsd.org/pf.conf>,
<https://en.wikipedia.org/wiki/Swiss_cheese_model>
For reasons such as these, CVE-2021-44228's CVSSv3 Environmental Score in
any particular deployment can easily result in a CVSSv3 overall score that's
lower than the Base Score. Thus, CVE-2021-44228 is not Nadia Comăneci.
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
