Stream: Security and Privacy
Topic: CVE-2021-44228
David Pyke (Dec 10 2021 at 20:10):
Check your use of Log4j, people: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-44228
John Moehrke (Dec 10 2021 at 20:31):
see. you should just use FHIR AuditEvent... ;-)
John Moehrke (Dec 10 2021 at 20:32):
I joke... this is important catch.
Andrea Downing (Dec 11 2021 at 18:07):
Wow all of infosec twitter is on this right now.
https://www.lunasec.io/docs/blog/log4j-zero-day/
John Moehrke (Dec 11 2021 at 18:10):
The IHE-ATNA crowd should be worried as the transport for IHE-ATNA AuditMessage is syslog, and the majority solution for syslog is log4j. That said, most of that stack is not likely to enable an injection; however it is still the stack, and thus should be a concern.
Andrea Downing (Dec 11 2021 at 18:43):
John Moehrke (Dec 11 2021 at 18:46):
just install log4k it is obviously the next version, right? ;-)
David Pyke (Dec 11 2021 at 19:02):
log4k is for TVs. Everyone knows that...
John Moehrke (Dec 11 2021 at 19:23):
8k is all the rage
Andrea Downing (Dec 11 2021 at 19:23):
Andrea Downing (Dec 13 2021 at 18:06):
Hey @John Moehrke @Grahame Grieve here is livestream.
Question: what's the coordinating/disclosure process for the FHIR Implementation community? https://www.youtube.com/watch?v=oC2PZB5D3Ys
John Moehrke (Dec 13 2021 at 18:14):
It is not clear to me that this specific CVE rises to the level that it needs to be addressed by the FHIR community. I think it might be argued that the IHE-ATNA community might need to be addressed, due to the fact that IHE-ATNA requires use of SYSLOG standard, and log4J is the major solution for that standard.
The reason I don't think it is a FHIR community issue is because there is no direct or indirect relationship between log4j and FHIR, like there is with IHE-ATNA.
I think this principle is important to factor, as otherwise we will be alarming the FHIR community for Every CVE issued. I don't think that is appropriate.
John Moehrke (Dec 13 2021 at 18:16):
Now, CVE related to a major implementation of JSON or HTTP would be something it would seem useful for us to think about, and create a process. This has been part of discussion following the Alissa Knight report. This has been part of the discussions around the creation of the HL7 "Implementer Division". This has not yet been started. Not clear when it will get goign
John Moehrke (Dec 13 2021 at 18:18):
This all said, there certainly are going to be implementations that have used log4j. They should be concerned about this, as they should be concerned about ANY vulnerability in the solutions they have assembled. But, it is up to these implementations to know what they have included in their solution; and to have Risk Management of these assembly.
Grahame Grieve (Dec 13 2021 at 18:19):
there are implementations that use log4j, and they've done their changes
John Moehrke (Dec 13 2021 at 18:19):
Which brings up an important aspect... Risk Management... Not all quick reactions need to be to apply the patch, eventually it should be applied. What I mean to explain is that managing risk is top priority, and that starts with identifying threats, and effects of those rhtreats
Andrea Downing (Dec 14 2021 at 00:48):
Erhm....for half of these FHIR implementations I wrote up a bespoke threat assessment.
Can I email you guys to review?
Grahame Grieve (Dec 14 2021 at 04:03):
sure
Last updated: Apr 12 2022 at 19:14 UTC
