add sending output format strings and templates lab

[jasinner]

The Log4J developers prior to CVE-2021-44228 allowed uses to load arbitrary variables (and code) from a remote JNDI server using the logging templates. This example comes from the patch for CVE-2021-44228, and is part of the fix for that vulnerability which restricts which JNDI server host one can load variables from.

[SecurityCRob]

@david-a-wheeler can you review Jason's submission please?

[david-a-wheeler]

I'm really sorry I didn't respond earlier, I somehow missed this.

Thanks so much for taking a stab at this! I also like the approach of using a known CVE, I think that can be helpful.

However, I don't think this lab best illustrates the ponit. This lab focuses on "Restrict the JNDI hostnames from which variables can be loaded." That's a lab on restricting the inputs that are allowed, and we already have a lab on that topic.

What we need is a lab that mirrors Format Strings and Templates. Now the weird thing is that we DO use this specific vulnerability as an example of the problem. However, what I meant when referring to this CVE is that if an attacker can cause any reaction simply by causing text of the form ${jndi:ldap://...} to trigger loading of external code, that's a problem. You're absolutely right that restricting the access to localhost greatly reduces the impact of the vulnerability, but really, allowing attackers to trigger random jndi at all is a problem, and the intent was to focus on that.

Can you modify the material so it's clearer that allowing an attacker to trigger any unexpected code execution, just via data that's output or logged, is a problem? Perhaps log4shell is not the clearest example, sorry about that.

[jasinner]

@david-a-wheeler What If we updated the Background section by adding:

"Allowing a user to load variables is still a security risk, even from the same host. However the program requirements might dictate it's necessary. We're going to assume that in this exercise it's required to load variables from a JNDI server on the same host, and disabling such functionality is not an option."

[david-a-wheeler]

That makes sense to me!

[david-a-wheeler]

However, it's not really dealing with the underlying issue I raised earlier.