Hello everyone,
As you may have heard, a serious security problem was recently discovered in the Log4j Java logging framework. KoBoToolbox does not use Log4j and therefore is not vulnerable to this problem.
If you’d like more detail: the only part of the KoBoToolbox server software that’s written in Java is ODK Validate. ODK Validate in turn uses a library called JavaRosa. Either of these could contain Log4j, but they do not; instead, they use SLF4J:
- validate/build.gradle at 79204416473845e3afa25074f47de67982d2d194 · getodk/validate · GitHub
- javarosa/build.gradle at 2b4dd8958a60d05f81b3806136d7ed11aedf5802 · getodk/javarosa · GitHub
- javarosa/pom.xml at 2b4dd8958a60d05f81b3806136d7ed11aedf5802 · getodk/javarosa · GitHub
You may further confirm for yourself that no Log4j classes appear in any JAR files on a KoBoToolbox server:
ubuntu@kobo-host:/$ sudo find -iname '*.jar' -exec unzip -l \{} \; 2>&1 | grep -i log4j
A search with the same technique for slf4j
, however, should return many results:
ubuntu@kobo-host:/$ sudo find -iname '*.jar' -exec unzip -l \{} \; 2>&1 | grep -i slf4j
0 2017-03-16 17:36 META-INF/maven/org.slf4j/
0 2017-03-16 17:36 META-INF/maven/org.slf4j/slf4j-nop/
109 2017-03-16 17:18 META-INF/maven/org.slf4j/slf4j-nop/pom.properties
786 2017-03-16 16:53 META-INF/maven/org.slf4j/slf4j-nop/pom.xml
…
If you disagree with this analysis, or you want to report a different security problem with KoBoToolbox, do not post it in a public venue like this forum or GitHub. Instead, send an email to info@kobotoolbox.org. Thank you!
John Milner
Lead Developer