Re: Log4j mitigation
Am 11.12.2021 um 04:54 schrieb Andy Ringsmuth :
>
> The intricacies of Java are over my head, but I’ve been reading about this
> Log4j issue that sounds pretty bad.
>
> What do we know about this? What, if anything, can a network operator do to
> help mitigate this? Or even an end user?
Probably not. The problem lies in the functionality of log4j to do token
interpolation (think "foo ${bar} baz") not just on the format string that is
configured, but also on the values passed into the logging function call.
Let that sit for a minute.
For most applications that receive input over the network, I would expect it's
close to impossible to recognise problematic input that might be logged while
processing the request, or even at a later stage. The URL is an obvious place,
but form input, or even the contents of a ZIP file that is being uploaded might
be processed by logging function calls.
The good news is that setting the Java system property
log4j2.formatMsgNoLookups to true disables the vulnerable functionality. For
most Java server applications, that should be a very quick change.
Stefan
--
Stefan BethkeFon +49 151 14070811
signature.asc
Description: Message signed with OpenPGP
Re: Log4j mitigation
Andy Ringsmuth wrote on 11/12/2021 03:54: The intricacies of Java are over my head, but I’ve been reading about this Log4j issue that sounds pretty bad. What do we know about this? What, if anything, can a network operator do to help mitigate this? Or even an end user? The payload can be contained in https, so there is no way of detecting / stopping this at the network level. Installations need to be upgraded / fixed. https://logging.apache.org/log4j/2.x/security.html 1. upgrade log4j to 2.15.0 and restart all java apps 2. start java with "-D log4j2.formatMsgNoLookups=true" (v2.10+ only) 3. start java with "LOG4J_FORMAT_MSG_NO_LOOKUPS=true" environment variable (v2.10+ only) 4. zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class There's a lot of scanning going on at the moment, so if you have an exposed java instance running something which includes log4j2, you may already be compromised. Nick
Re: Log4j mitigation
This is largely a patching exercise for people that use the software. If you use it, please patch. Sent via RFC1925 complaint device > On Dec 10, 2021, at 10:59 PM, Andy Ringsmuth wrote: > > The intricacies of Java are over my head, but I’ve been reading about this > Log4j issue that sounds pretty bad. > > What do we know about this? What, if anything, can a network operator do to > help mitigate this? Or even an end user? > > > Andy Ringsmuth > 5609 Harding Drive > Lincoln, NE 68521-5831 > (402) 304-0083 > a...@andyring.com
Re: questions about ARIN ipv6 allocation
On 10 Dec 2021, at 5:00 PM, John Gilmore mailto:g...@toad.com>> wrote: ... Owen, the root of your problem is that you signed an LRSA with ARIN, rather than keeping your legacy resources un-tainted by an ARIN contract that deliberately reduced your rights Signing a contract with ARIN certainly clarifies and makes specific the rights involved, but it is not possible to say “reduces” with any certainty as the existing rights are rather unclear without a specific statement of what rights were granted at the time. Alas, issuance of number resources in the early days did not make the rights or associated obligations clear. Some legacy resource holders find entering into an RSA with ARIN to be quite useful and others prefer not to – that choice is up to them, and is not required as the the ARIN Board of Trustees has directed that ARIN continue to provide the same basic registration services available at our formation to all legacy resource holders without fee or contract. The short-term contract for the transfer honors and retains the legacy status of those resources: that you own them, not the ARIN fiction that an RIR now controls them and will steal them from you if you stop paying them annually. For organizations that do enter into a registration agreement with ARIN, there are indeed obligations (such as payment of registry fees) that are quite real but also benefits such as the ability to obtain new services funded by such fees and participation in the governance of ARIN. As noted above - folks can enter into an agreement (or not) as they deem best. Note one of the other advantages of the upcoming change to ARIN’s fee structure is that it will also open up ARIN membership and voting to all contracted registry customers with IPv4 or IPv6 number resources – rather than just those previously deemed ISPs – so those who do enter into a RSA and choose to participate in ARIN governance will have the equal ability to vote for the Board and set ARIN’s practices with regard to legacy resource holders. Thanks, /John John Curran President and CEO American Registry for Internet Numbers
