Inguza Technology AB

technology, analysis and solutions

Debian Long Term Support work 2017 June

The following contributions were made:

  • LTS front desk activities week 23
    • Marked CVE-2017-9406 and CVE-2017-9408 for poppler as no-dsa following jessie and stretch. It is a memory leak and it should be seen as a minor issue. Especially considering this being primarily used in command line tools. Informed the poppler maintainer about this.
    • Analyzed CVE-2017-8378 and CVE-2017-8787 for libpodofo. Upstream have not solved the problem. So I looked at it and wrote two small patches that compiled fine. However when trying to reproduce the problem it turned out that the libpodofo-utils package (that is the most likely one to use this) could not get to the problematic scenario. It exited earlier than this. This means that it is probably not worth the effort fixing this in wheezy. The patches were sent to the two related Debian bugs so the maintainer is aware of the problem. Informed the maintainer that it is not worth fixing in wheezy.
    • Triaged CVE-2017-6886 and CVE-2017-6887 for libraw. The conclusion is that the vulnerable code is present (even fewer checks are done in wheezy) and it sounds nasty enough. It should be worth fixing. Informed the maintainer about this and added libraw to dla-needed.txt file.
    • Started triage of CVE-2017-9066 for wordpress but had to stop before I could conclude anything useful. It looks worth fixing. The remaining question is whether it was actually fixed in the recent wordpress upload.
    • Started looking through CVE-2017-9434 for libcrypto++. I could not understand how the code would not break down totally with and without the patch so I had to ask. After a day I got an answer to that. After reading the code a few more times I decided for minor issue. It is just out of bounds read, not out of bounds write so this should not be a major problem.
    • Triaged CVE-2017-9324 for otrs2. The information in the advisory was not very clear. Instead the CHANGES.md files was examined and also the diff from previous version was examined. From this a number of suspected files were found. Added the suspected changes in the CVE information. The exact problem was not found but it is clear that the package is vulnerable to something bad. Maintainer informed and package added to dla-needed.txt.
    • Triaged #864291 for samba. Even though upstream do not classify this as a security problem it is quite clearly a DoS class vulnerability and should be fixed. Also in wheezy. Maintainer informed and package added to dla-needed.txt.
    • Triaged CVE-2017-9066 for wordpress. Found the wheezy package vulnerable. Maintainer informed and package added to dla-needed.txt. Sent a mail to Craig asking of the other upload actually missed this vulnerability. The next day I investigated this further and concluded that all wordpress versions are affected (except when latest upstream is used) and I also concluded that the fix is rather different from latest wordpress. In essence calls to wp_remote_request(...location...) shall be replaced with wp_safe_remote_request(...location...)
    • Triaged CVE-2017-5664 for tomcat. After quite some effort I think I have concluded that even though jessie version of tomat6 is not vulnerable the wheezy version is. This means that both tomcat6 and tomcat7 are vulnerable. Informed maintainer about this and both packages were added to dla-needed.txt file. One of the reasons for the time to find this information was that it was not trivial to find what had actually been changed. Finally I could find the tomcat8 change and a slightly cleaned extract can be found here http://apt.inguza.net/wheezy-security/tomcat/tomcat8-CVE-2017-5664.patch. Emilio was so kind to tell that tomcat6 has reached end-of-life so CVE-2017-5664 was marked accordingly.
    • Did a quick triage of CVE-2017-0376 for tor. It looked very likely to be affected and as it was already in dsa-needed.txt then I simply contacted the maintainer and added to dla-needed.txt. The maintainer informed that he want to handle the package himself in time. He felt pushed. Not 100% sure why but I guess it is because the security team sends out a similar email.
    • Triaged CVE-2017-9462 for mercurial. Thanks to Wagner Bruna this was an easy task as the Debian bug #861243 was already updated with that the wheezy version was affected including a patch proposal for wheezy. Added to dla-needed.txt and informed the maintainer.
    • Triaged CVE-2017-9468 and CVE-2017-9469 for irssi. These two CVEs refer to the same patch. After source analysis the code should apply fairly cleanly meaning that the software is affected also in wheezy. Maintainer informed and package added to dla-needed.txt.
    • Started to triage CVE-2017-9110, CVE-2017-9111, CVE-2017-9112, CVE-2017-9113, CVE-2017-9114, CVE-2017-9115 and CVE-2017-9116 for openexr. The problem sounds serious which means that the package should probably be fixed. However when trying to reproduce the problem I failed to do so. I asked on github whether anyone have been able to reproduce the problem. After feedback I decided to treat 9110 to 9112 as affected and the rest as no-dsa. Added to dla-needed.txt and informed the maintainer. Did some analysis of the proposed patch:
      • IlmImf/ImfDwaCompressor.cpp (not affected, the vulnerable code do not exist in wheezy, in addition to that I can not find this mentioned in any of the CVEs)
      • IlmImf/ImfHuf.cpp (looks affected)
      • IlmImf/ImfPizCompressor.cpp (looks affected)
      • Some of the CVEs mention other files but they are not part of the proposed patch. See discussion on github for further information.
    • Started a discussion on whether we should send the email to maintainer if the maintainer have already been informed by the Stable Security team. Wiki was updated the week after as you can see below.
    • Marked CVE-2017-9525 for cron as no-dsa following stretch and jessie.
    • Triaged CVE-2017-8108 for lynis and the conclusion is that the vulnerable code do not exist in wheezy. This was concluded by taking a diff between 2.4.8 and 2.5.0 revision. Clearly the fix was just in include/tests_webservers. That fix was not necessary in wheezy version as the tests do nto re-use the temp file in the same way (the specific test was commented in wheezy). Also looked for similar use but did not find any in wheezy. Therefore marked accordingly (not-affected) in the security tracker.
    • Triaged CVE-2017-9520 for radare2 and concluded that it is a minor issue. Denial of service in reverse engineering tool or command line hex editor should really not be a big problem.
    • Updated the dla-needed.txt file and security tracker based on email input.
  • Did some updates to the LTS Development wiki (as follow up on the discussion thread started the week before) with instructions on what to considering when contacting the maintainer.