Re: addressing CVE-2018-1311/XERCESC-2188
Hi Sylvain,
> FYI it seems none of your messages made it to the Xerces c-dev mailing list:
> https://mail-archives.apache.org/mod_mbox/xerces-c-dev/202001.mbox/browser
>
> Are you still working on a patch?
unfortunately, I did not manage to find time for my LTS duties in february
and I doubt that it will be any different in march and april. Since I don't
want to slow down the work here, I will step back in the next two months.
Sylvain, it would be great if you could take over there.
Regarding the xerces-c mailing list: I don't know, I have tried to resend
the message multiple times from different addresses after properly
subscribing, and still they did not make it to the list.
thanks for the reminder.
regards,
Hugo
--
Hugo Lefeuvre (hle)|www.owl.eu.com
RSA4096_ 360B 03B3 BF27 4F4D 7A3F D5E8 14AA 1EB8 A247 3DFD
ed25519_ 37B2 6D38 0B25 B8A2 6B9F 3A65 A36F 5357 5F2D DC4C
signature.asc
Description: PGP signature
January LTS Report
Hi, Here is my LTS report for January 2020. I was allocated 12 hours. I have spent 5.5 of them in the following tasks: libexif: + investigate the issue, and come to the conclusion that a fix will be hard to obtain without access to the reproducer. Contact Ray Essick from Google on behalf of the LTS and security teams. Finally upstream released an official fix which I uploaded as DLA-2100-1. libfaad: + monitor and investigate a regression in a previous update. This is tracked upstream via [0]. Unfortunately I could not give this issue as much attention as I wanted to this month. xeres-c: + investigate CVE-2018-1311 and communicate a patch proposal [2]. The implementation is ongoing work and was limited by the amount of time I could invest in my LTS tasks this month. My priority is to get this upstreamed and uploaded in february. reportlab: + monitor & investigate. yet another complicated case... Upstream commited a patch which does not seem fit for release to me. See [1]. I intend to spend more time on this and take a final decision in the next few days. misc: + dla-needed triage, keep an eye on open, pending issues. + review qemu update from Utkarsh. The remaining hours will be returned to the pool. regards, Hugo [0] https://github.com/knik0/faad2/commit/a8dc3f8ce67f4069cfa4d5cf0fcc2c6e8ef2c2aa [1] https://lists.debian.org/debian-lts/2020/01/msg00056.html [2] https://lists.debian.org/debian-lts/2020/01/msg00055.html -- Hugo Lefeuvre (hle)|www.owl.eu.com RSA4096_ 360B 03B3 BF27 4F4D 7A3F D5E8 14AA 1EB8 A247 3DFD ed25519_ 37B2 6D38 0B25 B8A2 6B9F 3A65 A36F 5357 5F2D DC4C signature.asc Description: PGP signature
Re: addressing CVE-2018-1311/XERCESC-2188
Hi Ola, > > A DTDEntityDecl object is allocated and pushed into the ReaderMgr stack. > > ReaderMgr does not own the stack's content, so objects neither get freed on > > ReaderMgr::popReader(), nor on ReaderMgr::~ReaderMgr(). > > And it should not be freed by the code popping the object? I don't think so. In fact, the code popping the object is the ReaderMgr itself: popReader is a private method called by a higher level scanning API, e.g. ReaderMgr::getNextChar. $ ag popReader src/xercesc/internal/ReaderMgr.cpp 107:if (!popReader()) 129:if (!popReader()) 149:if (!popReader()) 166:if (!popReader()) 191:if (!popReader()) 214:if (!popReader()) 237:if (!popReader()) 256:if (!popReader()) 273:if (!popReader()) 1056:bool ReaderMgr::popReader() src/xercesc/internal/ReaderMgr.hpp 203:bool popReader(); > > A janitor is set to avoid leaking memory via the allocated DTDEntityDecl. > > Unfortunately the object is freed when the janitor gets out of scope, at > > which point a pointer to this object is still present within the stack. > > Do you mean that the janitor should not free it at this point? Exactly. This is too early! > > # I suggest the following fix: > > > > Add a `bool adopt` parameter to ReaderMgr::pushReader() (default value of > > false), and a `RefStackOf* fAdoptedStack` private element to > > the ReaderMgr class. > > > > Whenever ReaderMgr::pushReader() is called with `adopt` set to true, also > > push passed object onto `fAdoptedStack`. > > > > Whenever ReaderMgr::popReader() is called, check whether the object being > > removed is on top of `fAdoptedStack`. If so, remove and delete it. > > > > On ReaderMgr::~ReaderMgr(), delete `fAdoptedStack` and all possibly > > remaining elements. > > > > I assume that you also remove the janitor in this case? Yes! Thanks for having a look. Did I manage to answer your questions? If so, I'd go on, implement the patch and try to get some review from upstream. BTW, I don't think previous messages reached the c-dev mailing list. I tried to subscribe, let's see if this one does. FTR: initial message here[0]. cheers, Hugo [0] https://lists.debian.org/debian-lts/2020/01/msg00055.html -- Hugo Lefeuvre (hle)|www.owl.eu.com RSA4096_ 360B 03B3 BF27 4F4D 7A3F D5E8 14AA 1EB8 A247 3DFD ed25519_ 37B2 6D38 0B25 B8A2 6B9F 3A65 A36F 5357 5F2D DC4C signature.asc Description: PGP signature
Re: [CVE-2019-17026] Firefox Security Advisory 2020-03
Hi,
> It seems urgent to me to correct a flaw exploited in firefox:
> https://www.mozilla.org/en-US/security/advisories/mfsa2020-03/
>
> Here are the changes:
> https://raw.githubusercontent.com/HacKurx/public-sharing/master/firefox-68.4.0-1_js_src_jit_MIR.h.patch
AFAIK this has already been addressed in jessie via DLA-2061-1[0]
(firefox-esr) and DLA-2071-1 (thunderbird) on Jan, 09 2020.
thanks
cheers,
Hugo
[0] https://security-tracker.debian.org/tracker/CVE-2019-17026
--
Hugo Lefeuvre (hle)|www.owl.eu.com
RSA4096_ 360B 03B3 BF27 4F4D 7A3F D5E8 14AA 1EB8 A247 3DFD
ed25519_ 37B2 6D38 0B25 B8A2 6B9F 3A65 A36F 5357 5F2D DC4C
signature.asc
Description: PGP signature
Re: python-reportlab: CVE-2019-17626: remote code execution in colors.py
Hi,
a fix was recently published for this issue. I am concerned that it might
no be fit for a DSA/DLA:
(1) upstream imported a number of snippets from ZPL licensed projects. I
don't think it respected the ZPL terms.
(2) the changes are large and hard to review. Pretending that these changes
address the vulnerability completely would be a little bit presumptuous.
Furthermore, the code imported from Zope provides "safe" evaluation of
Python code. This kind of code is complex, and prone to security
vulnerabilities and bugs. There are definitely regressions in there.
I have asked upstream regarding the licensing issue. For the rest, I think
we should wait for followups, or possibly a better patch.
Any comments/advice?
cheers,
Hugo
--
Hugo Lefeuvre (hle)|www.owl.eu.com
RSA4096_ 360B 03B3 BF27 4F4D 7A3F D5E8 14AA 1EB8 A247 3DFD
ed25519_ 37B2 6D38 0B25 B8A2 6B9F 3A65 A36F 5357 5F2D DC4C
signature.asc
Description: PGP signature
addressing CVE-2018-1311/XERCESC-2188
[c-dev senders: please CC me, I did not subscribe to the mailing list]
Hi,
I had a look at CVE-2018-1311/XERCESC-2188 with the intention to provide a
patch.
This issue seems to be present at several places in the source code:
$ ag "Janitor"
src/xercesc/internal/IGXMLScanner.cpp
1535:Janitor janDecl(declDTD);
3098:Janitor janDecl(declDTD);
src/xercesc/internal/DGXMLScanner.cpp
1055:Janitor janDecl(declDTD);
2134:Janitor janDecl(declDTD);
# Issue summary
A DTDEntityDecl object is allocated and pushed into the ReaderMgr stack.
ReaderMgr does not own the stack's content, so objects neither get freed on
ReaderMgr::popReader(), nor on ReaderMgr::~ReaderMgr().
A janitor is set to avoid leaking memory via the allocated DTDEntityDecl.
Unfortunately the object is freed when the janitor gets out of scope, at
which point a pointer to this object is still present within the stack.
Later this freed pointer is dereferenced and one of its methods is called.
Assuming that the attacker managed to manipulate the heap with the right
timing, this leads to code execution.
The difficulty is that there is currently no good way to fix this: removing
the janitor will lead to a memory leak, and there is no callback called
when the ReaderMgr removes elements from the stack.
# I suggest the following fix:
Add a `bool adopt` parameter to ReaderMgr::pushReader() (default value of
false), and a `RefStackOf* fAdoptedStack` private element to
the ReaderMgr class.
Whenever ReaderMgr::pushReader() is called with `adopt` set to true, also
push passed object onto `fAdoptedStack`.
Whenever ReaderMgr::popReader() is called, check whether the object being
removed is on top of `fAdoptedStack`. If so, remove and delete it.
On ReaderMgr::~ReaderMgr(), delete `fAdoptedStack` and all possibly
remaining elements.
Feedback?
cheers,
Hugo
--
Hugo Lefeuvre (hle)|www.owl.eu.com
RSA4096_ 360B 03B3 BF27 4F4D 7A3F D5E8 14AA 1EB8 A247 3DFD
ed25519_ 37B2 6D38 0B25 B8A2 6B9F 3A65 A36F 5357 5F2D DC4C
signature.asc
Description: PGP signature
Re: [SECURITY] [DLA 2069-1] cacti security update
Hi Chris,
> > a followup patch was just published for CVE-2020-7106[0]. If you want to
> > release a regression update, I'd recommend to wait a few days.
>
> Thanks for spotting this and for your sage advice — I have added it to my
> calendar to recheck this shortly and will investigate and follow-up then.
thanks! Indeed, another followup seems to be coming for CVE-2020-7106,
I added a short note to dla-needed.
cheers,
Hugo
--
Hugo Lefeuvre (hle)|www.owl.eu.com
RSA4096_ 360B 03B3 BF27 4F4D 7A3F D5E8 14AA 1EB8 A247 3DFD
ed25519_ 37B2 6D38 0B25 B8A2 6B9F 3A65 A36F 5357 5F2D DC4C
signature.asc
Description: PGP signature
Re: RFT: qemu 1:2.1+dfsg-12+deb8u13
Hi Utkarsh, > > I've uploaded a snapshot of qemu 1:2.1+dfsg-12+deb8u13 to mentors.d.net. > > The relevant .dsc could be found here[1]. > > > > Whilst I think it should be safe to upload, I'd still appreciate a > > review to make sure that there's no regression. > > I will take a look at it in the evening. I did not have time to test the changes, however I have: - reviewed the debdiff carefully - compared with upstream changes - checked for discrepancies in the underlying macros - compiled and inspected the logs and everything looks fine to me! (That being said I would definitely not upload these changes without at least smoke testing slirp. :)) cheers, Hugo -- Hugo Lefeuvre (hle)|www.owl.eu.com RSA4096_ 360B 03B3 BF27 4F4D 7A3F D5E8 14AA 1EB8 A247 3DFD ed25519_ 37B2 6D38 0B25 B8A2 6B9F 3A65 A36F 5357 5F2D DC4C signature.asc Description: PGP signature
Re: RFT: qemu 1:2.1+dfsg-12+deb8u13
Hi Utkarsh, > I've uploaded a snapshot of qemu 1:2.1+dfsg-12+deb8u13 to mentors.d.net. > The relevant .dsc could be found here[1]. > > Whilst I think it should be safe to upload, I'd still appreciate a > review to make sure that there's no regression. I will take a look at it in the evening. thanks! Hugo -- Hugo Lefeuvre (hle)|www.owl.eu.com RSA4096_ 360B 03B3 BF27 4F4D 7A3F D5E8 14AA 1EB8 A247 3DFD ed25519_ 37B2 6D38 0B25 B8A2 6B9F 3A65 A36F 5357 5F2D DC4C signature.asc Description: PGP signature
Re: [SECURITY] [DLA 2069-1] cacti security update
Hi Chris, On Sat, Jan 18, 2020 at 02:01:07PM +, Chris Lamb wrote: > Package: cacti > Version: 0.8.8b+dfsg-8+deb8u9 > CVE ID : CVE-2020-7106 > > It was discovered that there were a number of cross-site scripting > vulnerabilities in cacti, a web interface for monitoring systems. > > For Debian 8 "Jessie", this issue has been fixed in cacti version > 0.8.8b+dfsg-8+deb8u9. > > We recommend that you upgrade your cacti packages. > > Further information about Debian LTS security advisories, how to apply > these updates to your system and frequently asked questions can be > found at: https://wiki.debian.org/LTS a followup patch was just published for CVE-2020-7106[0]. If you want to release a regression update, I'd recommend to wait a few days. I would not be surprised to see more fixes coming. :-) cheers, Hugo [0] https://github.com/Cacti/cacti/commit/47a000b5aba4af16967e249b25f25397506e3464 -- Hugo Lefeuvre (hle)|www.owl.eu.com RSA4096_ 360B 03B3 BF27 4F4D 7A3F D5E8 14AA 1EB8 A247 3DFD ed25519_ 37B2 6D38 0B25 B8A2 6B9F 3A65 A36F 5357 5F2D DC4C signature.asc Description: PGP signature
December LTS Report
Hi,
Here is my LTS report for December 2019.
I was allocated 12 hours. I have spent all of them in the following
tasks:
freeimage:
+ prepare, test and upload 3.15.4-4.2+deb8u2 (DLA-2031-1, DSA-4593-1).
+ investigate CVE-2019-12214 and CVE-2019-12212, finally postpone them.
xcftools:
+ create a reproducer for CVE-2019-5086 and write a patch (still waiting
for some external review).
+ start to investigate CVE-2019-5087.
imagemagick:
+ investigate regression #870273 and write a patch. Investigating this
issue was fairly painful, but I'm glad we managed to get rid of this 2+yo
regression.
+ prepare, test and upload 8:6.8.9.9-5+deb8u19 (DLA-2049-1).
libexif:
+ investigate CVE-2019-9278 and prepare a patch derived from the Android
fix (work in progress).
regards,
Hugo
--
Hugo Lefeuvre (hle)|www.owl.eu.com
RSA4096_ 360B 03B3 BF27 4F4D 7A3F D5E8 14AA 1EB8 A247 3DFD
ed25519_ 37B2 6D38 0B25 B8A2 6B9F 3A65 A36F 5357 5F2D DC4C
signature.asc
Description: PGP signature
Re: imagemagick: regression in 8:6.8.9.9-5+deb8u10
> Looks like I found the issue: > > 0224-Ensure-token-does-not-overflow.patch corresponds to [0]. This patch > was meant for ImageMagick 7.x, not 6.x. The correct patch is [1] (the one > used in stretch). > > This will be fixed in the next security update. Not completely true. After spending some more time on this issue, I found out that the following three patches are missing in jessie: https://github.com/ImageMagick/ImageMagick6/commit/fc8ccba0f20ca330d959fcbb17a791e5b52ac53e https://github.com/ImageMagick/ImageMagick6/commit/7573b8712697a3d34143eb3e6ea814287cc4c6a7 https://github.com/ImageMagick/ImageMagick6/commit/4cc316818e5b841ff5a9394a0730d5be6e8686ce backporting them is sufficient to fix the issue. cheers, Hugo -- Hugo Lefeuvre (hle)|www.owl.eu.com RSA4096_ 360B 03B3 BF27 4F4D 7A3F D5E8 14AA 1EB8 A247 3DFD ed25519_ 37B2 6D38 0B25 B8A2 6B9F 3A65 A36F 5357 5F2D DC4C signature.asc Description: PGP signature
Re: imagemagick: regression in 8:6.8.9.9-5+deb8u10
> I'm working on imagemagick on behalf of the Debian LTS team and just > noticed this bug report. > > I have reproduced this issue in jessie, and can confirm that this > regression is still present in 8:6.8.9.9-5+deb8u18. I can also confirm > that the regression was introduced between patch 0224 and 0227. > > I'll try to ship a patch for this along with the next jessie update. Looks like I found the issue: 0224-Ensure-token-does-not-overflow.patch corresponds to [0]. This patch was meant for ImageMagick 7.x, not 6.x. The correct patch is [1] (the one used in stretch). This will be fixed in the next security update. cheers, Hugo [0] https://github.com/ImageMagick/ImageMagick/commit/4b85d29608d5bc0ab641f49e80b6cf8965928fb4 [1] https://github.com/ImageMagick/ImageMagick6/commit/663e70e90257797f4634ea8dd4a31e0947d1f266 -- Hugo Lefeuvre (hle)|www.owl.eu.com RSA4096_ 360B 03B3 BF27 4F4D 7A3F D5E8 14AA 1EB8 A247 3DFD ed25519_ 37B2 6D38 0B25 B8A2 6B9F 3A65 A36F 5357 5F2D DC4C signature.asc Description: PGP signature
Re: imagemagick: regression in 8:6.8.9.9-5+deb8u10
Hi,
I'm working on imagemagick on behalf of the Debian LTS team and just
noticed this bug report.
I have reproduced this issue in jessie, and can confirm that this
regression is still present in 8:6.8.9.9-5+deb8u18. I can also confirm
that the regression was introduced between patch 0224 and 0227.
I'll try to ship a patch for this along with the next jessie update.
regards,
Hugo
--
Hugo Lefeuvre (hle)|www.owl.eu.com
RSA4096_ 360B 03B3 BF27 4F4D 7A3F D5E8 14AA 1EB8 A247 3DFD
ed25519_ 37B2 6D38 0B25 B8A2 6B9F 3A65 A36F 5357 5F2D DC4C
signature.asc
Description: PGP signature
November LTS Report
Hi,
Here is my LTS report for November 2019.
I was allocated 24.5 hours. I have spent 1.75 of them in the following
tasks:
pam-python:
+ cleanup various inconsistencies in the bug and security tracker, release
DLA-2000-1 for 1.0.4-1.1+deb8u1.
freeimage:
+ start work on a jessie upload including my recently merged patch.
clamav:
+ coordinate for a jessie update.
I had some difficulties to work this month and needed to take some time off
from Debian. Taking a look back, I was not far from burning out. I am
planning to continue my work in the next months, but will reduce my
assigned hours to 12. This month's 22.75 remaining hours will be returned
to the pool.
regards,
Hugo
--
Hugo Lefeuvre (hle)|www.owl.eu.com
RSA4096_ 360B 03B3 BF27 4F4D 7A3F D5E8 14AA 1EB8 A247 3DFD
ed25519_ 37B2 6D38 0B25 B8A2 6B9F 3A65 A36F 5357 5F2D DC4C
signature.asc
Description: PGP signature
October LTS Report
Hi, Here is my LTS report for October 2019. I was allocated 46.5 hours (22.75h + 23.75h from last month). I have spent all of them in the following tasks: clamav: + Backport 0.101.4+dfsg-0+deb9u1 to jessie in order to fix the Zip bomb issues (DLA-1953-1). This triggered an ABI transition, requiring additional uploads to dansguardian, havp, python-pyclamav and c-icap-modules. Note: tests were long, especially regarding c-icap-modules because I stumbled across a variety of bugs. I even needed to fix a Debian packaging bug in order to test the package properly. This update/transition was not trivial and a regression was found: - https://alioth-lists.debian.net/pipermail/pkg-clamav-devel/2019-October/007497.html I addressed this issue in DLA-1953-2. openjpeg2: + Triage CVE-2018-21010. Prepare, test and upload a jessie update addressing this issue (DLA-1950-1). Prepare, test and submit a stretch-pu update addressing this issue (2.1.2-1.1+deb9u4). libsdl1.2: + Prepare test and upload regression update for libsdl1.2 (DLA-1713-2). libsdl2: + Prepare test and upload regression update for libsdl2 (DLA-1714-2). cacti: + Reproduce CVE-2019-16723, produce a detailed report and get it reviewed by upstream. Not affected in the end. pam-python: + Start to investigate, open bug report and ask upstream for more information. Still ongoing, the maintainer will handle the update. imagemagick: + Investigate CVE-2019-17540, open bug report and ask Dirk Lemstra for more information. Update mitre CVE entry. Following this: prepare, test and upload a security update for imagemagick (DLA-1968-1). freeimage: + Write a patch for CVE-2019-12211: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=929597 To be upstreamed before releasing a DLA. python-reportlab: + Investigate CVE-2019-17626, still no upstream fix yet. & various misc triage regards, Hugo -- Hugo Lefeuvre (hle)|www.owl.eu.com RSA4096_ 360B 03B3 BF27 4F4D 7A3F D5E8 14AA 1EB8 A247 3DFD ed25519_ 37B2 6D38 0B25 B8A2 6B9F 3A65 A36F 5357 5F2D DC4C signature.asc Description: PGP signature
CVE-2019-17540 in imagemagick: fixing commits?
Hi, imagemagick is affected by CVE-2019-17540[0][1], a heap-based buffer overflow in ReadPSInfo in coders/ps.c. According to MITRE, this issue was fixed in 7.0.8-54[2]. The Debian LTS and security teams would like to determine the status of this vulnerability in Debian jessie, stretch and buster. However very little information is available regarding this issue and fixing commits. After some research, I found the following four commits. The issue addressed by these commits could possibly correspond to CVE-2019-17540[0][1]. https://github.com/ImageMagick/ImageMagick/commit/668d6a970553a94b0a2e378afda1d37abac94b5c https://github.com/ImageMagick/ImageMagick/commit/9667a9034a5eeedb30dfb18cfd1083ff32fd679b https://github.com/ImageMagick/ImageMagick/commit/73dd03cfb57f8f8c0a732fa062b9966ec7bf2f91 https://github.com/ImageMagick/ImageMagick/commit/e868e227085463932c5db32e5e0f27e306a0eb95 Can confirm that these commits correspond to CVE-2019-17540, as described in [1]? If this is not the case, do you have any additional information regarding this issue? thanks! regards, Hugo [0] https://security-tracker.debian.org/tracker/CVE-2019-17540 [1] https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=15826 [2] https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-17540 -- Hugo Lefeuvre (hle)|www.owl.eu.com RSA4096_ 360B 03B3 BF27 4F4D 7A3F D5E8 14AA 1EB8 A247 3DFD ed25519_ 37B2 6D38 0B25 B8A2 6B9F 3A65 A36F 5357 5F2D DC4C signature.asc Description: PGP signature
Re: cacti: CVE-2019-16723
Hi Salvatore, Paul,
I had a look at this issue in jessie, stretch and buster. I concluded that
jessie and stretch are not affected. I have reproduced the issue in buster.
# Quick breakdown:
Graphs are retrieved using rrdtool_function_graph() from lib/rrd.php, this
is true for jessie onwards.
rrdtool_function_graph() has a check for permissions, which is in fact very
similar to the ones introduced in 7a6a17252 and c7cf4a26e.
Before cf73ae1a9f65b5a27d7f9d10c8e14835c3a76326[0] this check in
rrdtool_function_graph() was always executed. After this commit the check
is only executed when $user > 0.
Note: 0 is the default value for $user:
[lib/rrd.php:1179][1]
function rrdtool_function_graph($local_graph_id, $rra_id, $graph_data_array,
$rrdtool_pipe = '', &$xport_meta = array(), $user = 0) {
...
However graph_image.php, graph_json.php and rrdtool_function_xport() call
rrdtool_function_graph() without passing $user:
[graph_image.php:132][2]
$output = rrdtool_function_graph(get_request_var('local_graph_id'),
$rra_id, $graph_data_array);
Hence, permissions are never checked after this commit. I don't think this
is the intended affect.
Now, let's try something: take 1.2.2+ds1-2+deb10u1, the version in buster
which is affected and simply revert cf73ae1a9f65b5a27d7f9d10:
--- a/lib/rrd.php 2019-10-16 13:24:08.590183640 +0200
+++ b/lib/rrd.php 2019-10-16 13:24:34.302046280 +0200
@@ -1171,11 +1171,11 @@
/* before we do anything; make sure the user has permission to view
this graph,
if not then get out */
- if ($user > 0) {
+ //if ($user > 0) {
if (!is_graph_allowed($local_graph_id, $user)) {
return 'GRAPH ACCESS DENIED';
}
- }
+ //}
if (getenv('LANG') == '') {
putenv('LANG=' . str_replace('-', '_', CACTI_LOCALE) .
'.UTF-8');
Try to reproduce: this is sufficient to "fix" the issue and appears to
confirm previous analysis.
Any comments?
cheers,
Hugo
[0]
https://github.com/Cacti/cacti/commit/cf73ae1a9f65b5a27d7f9d10c8e14835c3a76326
[1] https://github.com/Cacti/cacti/blob/develop/lib/rrd.php#L1179
[2] https://github.com/Cacti/cacti/blob/develop/graph_image.php#L132
--
Hugo Lefeuvre (hle)|www.owl.eu.com
RSA4096_ 360B 03B3 BF27 4F4D 7A3F D5E8 14AA 1EB8 A247 3DFD
ed25519_ 37B2 6D38 0B25 B8A2 6B9F 3A65 A36F 5357 5F2D DC4C
signature.asc
Description: PGP signature
Publishing advisories for regression updates on the website
Hi,
it looks like we don't publish advisories for regression updates on the
website (and neither does the security team). We have discussed this on IRC
yesterday and it seemed consensual that doing it would be a good idea.
parse-dla.pl handles regression updates correctly, so we only need to state
clearly that we either (1) do it or (2) don't do it, and document it in the
wiki. If we decide to do it, it would be nice to publish missing advisories
from previous regression updates as well?
cheers,
Hugo
--
Hugo Lefeuvre (hle)|www.owl.eu.com
RSA4096_ 360B 03B3 BF27 4F4D 7A3F D5E8 14AA 1EB8 A247 3DFD
ed25519_ 37B2 6D38 0B25 B8A2 6B9F 3A65 A36F 5357 5F2D DC4C
signature.asc
Description: PGP signature
Re: Bug#942172: clamav-daemon: After upgrade, clamd cannon create /var/run/clamav/clamd.ctl and stop.
Hi Filipe, Sebastian, > I could only test from 0.100.0+dfsg-0+deb8u1 as I couldn't find > 0.100.3+dfsg-0+deb8u1 anywhere in the archives and I'm out of servers > running clamav-daemon 0.100.3+dfsg-0+deb8u1; but as /run/clamav/ is root > owned in 0.100.0+dfsg-0+deb8u1 and clamav-daemon 0.101.4+dfsg-0+deb8u2 got > started without a problem after the upgrade I'd say it's OK. thanks for your time. I have done some more tests myself and went ahead with the upload, I hope everything will be fine now. Sorry for the trouble. If you see anything suspicious, don't hesitate to open a bug report, I will take a look at it. regards, Hugo -- Hugo Lefeuvre (hle)|www.owl.eu.com RSA4096_ 360B 03B3 BF27 4F4D 7A3F D5E8 14AA 1EB8 A247 3DFD ed25519_ 37B2 6D38 0B25 B8A2 6B9F 3A65 A36F 5357 5F2D DC4C signature.asc Description: PGP signature
Re: clamav-daemon: After upgrade, clamd cannon create /var/run/clamav/clamd.ctl and stop.
Hi Filipe,
> I did strike this in three boxes. Straight upgrade but opted not to touch
> config when asked. Don't know if it matters. However I did not find any
> reference to /etc/systemd/system/clamav-daemon.service.d/extend.conf in the
> package scripts as in stretch.
>
> The chown did make the difference. And the extend.conf prior to the upgrade
> on further two boxes got the upgrade working, AFAICT.
thanks for your answer.
After further investigations, I have found a probable cause for this issue:
debian/patches/clamd_dont_depend_on_clamav_demon_socket.patch was
mistakenly backported from the stretch upload.
This should not have been backported, because the jessie package is still
providing the systemd socket, which was removed from the stretch package in
0.99.2+dfsg-3 because of #824042[0].
I did not backport this removal because I considered it too intrusive for a
security upload. Looking back, this was maybe a mistake because it
increased the complexity of the backport.
I have prepared a regression update addressing this issue. It would be a
true benefit for the quality of this upload if somebody could give it a try
before I go on with uploading. You can find (UNRELEASED) amd64 builds,
signed by myself on my Debian webpage:
https://people.debian.org/~hle/lts/clamav/
regards,
Hugo
[0] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=824042
--
Hugo Lefeuvre (hle)|www.owl.eu.com
RSA4096_ 360B 03B3 BF27 4F4D 7A3F D5E8 14AA 1EB8 A247 3DFD
ed25519_ 37B2 6D38 0B25 B8A2 6B9F 3A65 A36F 5357 5F2D DC4C
signature.asc
Description: PGP signature
Re: clamd update, some tests failing
Hi Marc, > 42,43c42,43 > < /usr/share/clamav-testfiles/clam-v2.rar: Clamav.Test.File-6 FOUND > < /usr/share/clamav-testfiles/clam-v3.rar: Clamav.Test.File-6 FOUND > --- > > /usr/share/clamav-testfiles/clam-v2.rar: OK > > /usr/share/clamav-testfiles/clam-v3.rar: OK > 49c49 > < Infected files: 41 > --- > > Infected files: 39 Unless I am mistaken, this is the expected behavior. I did not update libclamunrar9 which is non-free, so these two files are not even processed by clamav. team: I thought that we were not supporting non-free packages. What is our policy on this matter? cheers, Hugo -- Hugo Lefeuvre (hle)|www.owl.eu.com RSA4096_ 360B 03B3 BF27 4F4D 7A3F D5E8 14AA 1EB8 A247 3DFD ed25519_ 37B2 6D38 0B25 B8A2 6B9F 3A65 A36F 5357 5F2D DC4C signature.asc Description: PGP signature
Re: libsdl2 patches cause regressions in Jessie
Hi Abhijith, > >> Looks like I'm actually not the one who issued this update. Abhijith: do > >> you want to handle this, or should I proceed with a fix tomorrow? > > I will look into it. Well... I ended up preparing the update and planned to upload it this afternoon after a few more tests. > > I have added a libsdl1.2 entry to dla-needed, will handle the update, then. > > As the initial mail says regression is on libsdl2. Can you let me know > why you added libsdl1.2 to the dla-needed ? Unless I am mistaken, there is another regression in libsdl1.2, the update was missing this patch[0]. I forgot to add an entry for libsdl2. cheers, Hugo [0] https://hg.libsdl.org/SDL/rev/32075e9e2135 -- Hugo Lefeuvre (hle)|www.owl.eu.com RSA4096_ 360B 03B3 BF27 4F4D 7A3F D5E8 14AA 1EB8 A247 3DFD ed25519_ 37B2 6D38 0B25 B8A2 6B9F 3A65 A36F 5357 5F2D DC4C signature.asc Description: PGP signature
Re: libsdl2 patches cause regressions in Jessie
> Unless I am mistaken, there is another regression in libsdl1.2, the update
> was missing this patch[0].
>
> I forgot to add an entry for libsdl2.
the dla-needed entry was confusing, indeed. I have updated it to reflect
the current situation.
--
Hugo Lefeuvre (hle)|www.owl.eu.com
RSA4096_ 360B 03B3 BF27 4F4D 7A3F D5E8 14AA 1EB8 A247 3DFD
ed25519_ 37B2 6D38 0B25 B8A2 6B9F 3A65 A36F 5357 5F2D DC4C
signature.asc
Description: PGP signature
Re: libsdl2 patches cause regressions in Jessie
On Mon, Oct 07, 2019 at 11:22:45PM +0200, Hugo Lefeuvre wrote:
> > This looks like a regression, indeed. I will provide a regression update
> > as soon as possible.
>
> Looks like I'm actually not the one who issued this update. Abhijith: do
> you want to handle this, or should I proceed with a fix tomorrow?
I have added a libsdl1.2 entry to dla-needed, will handle the update, then.
cheers,
Hugo
--
Hugo Lefeuvre (hle)|www.owl.eu.com
RSA4096_ 360B 03B3 BF27 4F4D 7A3F D5E8 14AA 1EB8 A247 3DFD
ed25519_ 37B2 6D38 0B25 B8A2 6B9F 3A65 A36F 5357 5F2D DC4C
signature.asc
Description: PGP signature
Re: libsdl2 patches cause regressions in Jessie
> This looks like a regression, indeed. I will provide a regression update
> as soon as possible.
Looks like I'm actually not the one who issued this update. Abhijith: do
you want to handle this, or should I proceed with a fix tomorrow?
cheers,
Hugo
--
Hugo Lefeuvre (hle)|www.owl.eu.com
RSA4096_ 360B 03B3 BF27 4F4D 7A3F D5E8 14AA 1EB8 A247 3DFD
ed25519_ 37B2 6D38 0B25 B8A2 6B9F 3A65 A36F 5357 5F2D DC4C
signature.asc
Description: PGP signature
Re: libsdl2 patches cause regressions in Jessie
Hi, > If my understanding is correct, some patches in libsdl2 > (2.0.2+dfsg1-6+deb8u1) as applied in Jessie cause issues because they were > intended for libsdl1.2, not libsdl2. > The patch for CVE-2019-7637 causes regressions (more info here > <https://bugzilla.novell.com/show_bug.cgi?id=1124825>), the commit here > <https://hg.libsdl.org/SDL/rev/81a4950907a0> fixes the CVE. > The patch for CVEs CVE-2019-7635, CVE-2019-7638 and CVE-2019-7636 has > unreachable code. The commit here > <https://hg.libsdl.org/SDL/rev/7c643f1c1887> fixes CVE-2019-7635 and the > commit here <https://hg.libsdl.org/SDL/rev/07c39cbbeacf> fixes CVEs > CVE-2019-7638 and CVE-2019-7636. This looks like a regression, indeed. I will provide a regression update as soon as possible. regards, Hugo -- Hugo Lefeuvre (hle)|www.owl.eu.com RSA4096_ 360B 03B3 BF27 4F4D 7A3F D5E8 14AA 1EB8 A247 3DFD ed25519_ 37B2 6D38 0B25 B8A2 6B9F 3A65 A36F 5357 5F2D DC4C signature.asc Description: PGP signature
Re: ClamAV update in jessie
Hi Salvatore, > I would say it depends a bit, I would say. It might be clear, but just > to be on safe side stating it here: the CVEs fixed for clamav are not > to be associated with those rebuild packages as well. > > I was thinking if I remember similar cases for DSAs. Let me see, on > top of the head I do not recall actually much such special cases. Only > two I remembered and looked up, there might be more! > > DSA-3433-1 was a case where we needed an update for ldb first, and > then a rebuild of samba as well with that version in place. So not > really exactly what you have here. > > CVE-2013-7439 was another case, more similar to the one which is to be > handled by you. As the list there was too long, we decided back then > to put the list in the tracker, this is not very optimal though. If > you have only those couple of rebuilds, then you simply can state this > in the DLA for clamav, that package x, y and z are to be rebuild for > the ABI changes. > > Of course you can decide to release single DLAs for the 'package > update due to the need of rebuild', but I guess it should be made > clear then in the text of the DLA that they are just needed due to the > ABI change in clamav. Thanks for these advices. Indeed, releasing security advisories for rebuilds (which are, in the end, non-security related issues) doesn't sound right. Releasing a single DLA similar to dsa-3224 is probably the best option, and instead of pointing to the tracker I would just explain the situation and list the four reverse dependencies. cheers, Hugo -- Hugo Lefeuvre (hle)|www.owl.eu.com RSA4096_ 360B 03B3 BF27 4F4D 7A3F D5E8 14AA 1EB8 A247 3DFD ed25519_ 37B2 6D38 0B25 B8A2 6B9F 3A65 A36F 5357 5F2D DC4C signature.asc Description: PGP signature
Re: ClamAV update in jessie
Hi,
> thanks, something in that order of magnitude is ok...
Ack, I have prepared updates for clamav and the four reverse dependencies,
currently testing them.
This is going to be my first time organizing a transition in
jessie-security, so a few things are still unclear to me.
Obviously clamav should be uploaded first. This will, however, break the
reverse dependencies, i.e. they should be uploaded as soon as possible
after clamav.
I plan to upload reverse dependencies as soon as all clamav builds
succeeded and clamav binary packages are available in the archive. I don't
think they would build if I uploaded them earlier.
Regarding the DLAs. I plan to release a DLA per upload (one DLA for clamav
and one for each reverse dependency). Announcing all five uploads under a
single DLA seems a bit messy to me.
Any comment?
regards,
Hugo
--
Hugo Lefeuvre (hle)|www.owl.eu.com
RSA4096_ 360B 03B3 BF27 4F4D 7A3F D5E8 14AA 1EB8 A247 3DFD
ed25519_ 37B2 6D38 0B25 B8A2 6B9F 3A65 A36F 5357 5F2D DC4C
signature.asc
Description: PGP signature
Re: ClamAV update in jessie
Hi Holger, > > This work has already been done for stretch, so we should be able to > > backport it to jessie. Still, I'm going to spend quite some time on it... > > what does 'some time' mean? in general, this seems reasonable to me. The debdiffs are fairly simple, and the versions are close. Probably six hours altogether, but this is a rough estimation. FTR, the transition in stretch was tracked as #924278[0]. cheers, Hugo [0] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=924278 -- Hugo Lefeuvre (hle)|www.owl.eu.com RSA4096_ 360B 03B3 BF27 4F4D 7A3F D5E8 14AA 1EB8 A247 3DFD ed25519_ 37B2 6D38 0B25 B8A2 6B9F 3A65 A36F 5357 5F2D DC4C signature.asc Description: PGP signature
ClamAV update in jessie
Hi, I've spent a couple of hours working on ClamAV since yesterday. I have backported Sebastian Andrzej Siewior's work to jessie, and tested it. Fine so far, this fixes a couple of issues including the Zip bomb ones. Problem: we're backporting 0.101.4 to jessie. This implies an ABI bump and unless I am mistaken requires uploads for a few reverse dependencies: - python-pyclamav - havp - dansguardian - libc-icap-mod-virus-scan This work has already been done for stretch, so we should be able to backport it to jessie. Still, I'm going to spend quite some time on it... I'd like to know what you think about this, and if you can think of any alternative/less time consuming solution. (cherry picking changes does not seem reasonable to me) regards, Hugo -- Hugo Lefeuvre (hle)|www.owl.eu.com RSA4096_ 360B 03B3 BF27 4F4D 7A3F D5E8 14AA 1EB8 A247 3DFD ed25519_ 37B2 6D38 0B25 B8A2 6B9F 3A65 A36F 5357 5F2D DC4C signature.asc Description: PGP signature
September LTS Report
Hi, Here is my LTS report for September 2019. I was allocated 23.75h. Unfortunately I did not manage to spend any of them. Last month was very busy on the personal side, and I had to temporarily pause my Debian involvement. Everything should be back to normal now, and I expect to be able to spend these hours in october. regards, Hugo -- Hugo Lefeuvre (hle)|www.owl.eu.com RSA4096_ 360B 03B3 BF27 4F4D 7A3F D5E8 14AA 1EB8 A247 3DFD ed25519_ 37B2 6D38 0B25 B8A2 6B9F 3A65 A36F 5357 5F2D DC4C signature.asc Description: PGP signature
Re: since update 1.3.3.5-4+deb8u5 php ldap authentification failure
Hi, Sorry for the very late answer. For some reason, it looks like the LTS team was not aware of this bug... I am the one who provided these updates. This issue must have slipped through my LDAP tests. I will investigate this as soon as possible and provide a fix consequently. Mike, you did the latest 389-ds-base update. Did you notice anything wrong during your tests? Thanks! regards, Hugo -- Hugo Lefeuvre (hle)|www.owl.eu.com RSA4096_ 360B 03B3 BF27 4F4D 7A3F D5E8 14AA 1EB8 A247 3DFD ed25519_ 37B2 6D38 0B25 B8A2 6B9F 3A65 A36F 5357 5F2D DC4C signature.asc Description: PGP signature
Re: About the security issues affecting imagemagick in Jessie
Hi Mike, > I find that the below package / CVE states make front-desk life easy and > clear: > > - package has been claimed > - a CVE is tagged with > - a CVE is tagged with > - a CVE is vulnerable > - a CVE is fixed Should we completely stop using then? This makes sense for the security team, but is it useful in the LTS case? I'm not sure myself. I usually use no-dsa when a CVE is minor but I didn't take a final decision (ignore it/postpone it) yet (not enough time, no "need" to take a final decision, can be revisited). > The tag is a bit of a dodgy statement here (it should be worked > upon, but later when some other more severe issue pops up for the same > package, or when some feedback is received, or when ). > > So, a tag can in fact mean anything. When being at front-desk > you have to dig into the details (security-tracker comments, older mailing > list threads, etc.) to understand the nature of individual tags. > This is awkward IMHO. I don't think so. entries don't have to be revisited unless new issues pop up for which we want to release a DLA. Most of the time when I tag I mean "this is really minor, preparing an update just for that would be wasting our time. regression risks are very low though, so let's ship it in an future update". > Regarding imagemagick, CVE-2019-13308 and CVE-2019-13391 are postponed, > because upstream feedback is required. CVE-2019-14981 is postponed until > something more severe needs fixing. > > IMHO, CVE-2019-13308 and CVE-2019-13391 are a good reason for keeping > imagemagick in dla-needed.txt and also keeping it claimed by the person who > sent out the requests for feedback to upstream. Regarding CVE-2019-13308 and CVE-2019-13391, I meant "revisit these when preparing the next update, as of now I don't want to apply this undocumented, large, potentially incomplete patch". Also, the issue is uncritical, no hurry. We can just take a look at this when new issues pop up for imagemagick. This is borderline, so let's stop wasting time: we can keep a dla-needed entry with appropriate comments for both front desk and regular lts contributors. cheers, Hugo -- Hugo Lefeuvre (hle)|www.owl.eu.com RSA4096_ 360B 03B3 BF27 4F4D 7A3F D5E8 14AA 1EB8 A247 3DFD ed25519_ 37B2 6D38 0B25 B8A2 6B9F 3A65 A36F 5357 5F2D DC4C signature.asc Description: PGP signature
Re: About the security issues affecting imagemagick in Jessie
Hi Mike, > > I have recently worked on these issues (in the last two weeks, in fact). :-) > > > > Most of these issues are no-dsa, either very minor from a security point of > > view or the patches are too unclear/unstable to be applied currently. > > > > The only recently postponed issue is CVE-2019-13391/CVE-2019-13308. I did > > not > > upload this patch because it is big, not really understandable, and > > undocumented. Upstream did not answer my questions yet. > > > > I'd just remove imagemagick from dla-needed and wait some time, until > > upstream > > clarifies this patch. If he doesn't, I'd just mark this no-dsa. > > can you rather document imagemagick (by adding a short version of the above > as a note) in dla-needed.txt so that the person at front desktop knows. Yes I can do that, but it sounds like a misusage of dla-needed to me. Does it make sense to have a dla-needed entry for imagemagick if we don't intend to release any DLA for these issues (yet)? > If you think that imagemagick has many issues, we should ignore for jessie > LTS, would it be appropriate to tag them as ignored in data/CVE/list? > > Otherwise they pop up again and again in lts-cve-triage.py. I have done some more triage. However please note that these issues pop up in lts-cve-triage because they are still open in stretch. The security team is currently working on imagemagick, so this should be fixed in the next weeks. cheers, Hugo -- Hugo Lefeuvre (hle)|www.owl.eu.com RSA4096_ 360B 03B3 BF27 4F4D 7A3F D5E8 14AA 1EB8 A247 3DFD ed25519_ 37B2 6D38 0B25 B8A2 6B9F 3A65 A36F 5357 5F2D DC4C signature.asc Description: PGP signature
Re: About the security issues affecting imagemagick in Jessie
Hi Mike, > The Debian LTS team recently reviewed the security issue(s) affecting your > package in Jessie: > https://security-tracker.debian.org/tracker/source-package/imagemagick > > We decided that a member of the LTS team should take a look at this > package, although the security impact of still open issues is low. When > resources are available on our side, one of the LTS team members will > start working on fixes for those minor security issues, as we think that > the jessie users would most certainly benefit from a fixed package. I have recently worked on these issues (in the last two weeks, in fact). :-) Most of these issues are no-dsa, either very minor from a security point of view or the patches are too unclear/unstable to be applied currently. The only recently postponed issue is CVE-2019-13391/CVE-2019-13308. I did not upload this patch because it is big, not really understandable, and undocumented. Upstream did not answer my questions yet. I'd just remove imagemagick from dla-needed and wait some time, until upstream clarifies this patch. If he doesn't, I'd just mark this no-dsa. regards, Hugo -- Hugo Lefeuvre (hle)|www.owl.eu.com RSA4096_ 360B 03B3 BF27 4F4D 7A3F D5E8 14AA 1EB8 A247 3DFD ed25519_ 37B2 6D38 0B25 B8A2 6B9F 3A65 A36F 5357 5F2D DC4C signature.asc Description: PGP signature
August LTS Report
Hi,
Here is my LTS report for August 2019.
I was allocated 30.5h. I have spent all of them in the following tasks:
xymon:
+ Backport stretch security update to jessie, test it (DLA-1898-1).
389-ds-base:
+ Triage CVE-2019-10224: not affected in the end, but the situation was a bit
messy and it took longer than expected.
imagemagick:
+ Continue my triage work: this took *a lot* of time, for a variety of reasons:
upstream does not provide clear security fixes, does not provide clear commit
messages or any kind of information relative to changes. I have found
additional security relevant issues in the source code and suggested a
number of changes to upstream's patches.
+ Following the triage, prepare the security update (DLA-1888-1).
libsdl2:
+ Triage work for CVE-2019-13616 and CVE-2019-13626: this also turned out to be
longer than expected because upstream did not provide clear indications about
which patch exactly fixed CVE-2019-13626.
tika:
+ Triage work for recent CVEs, research upstream fixes and ask for
confirmation.
+ Upload did not happen yet, because I encountered difficulties while
backporting the patches to jessie. Furthemore, I could not clearly assess
that
jessie is affected. I am still actively working on this and plan to finish
next month.
clamav:
+ Work on clamav's zip bomb issue. Open bug report, triage.
+ Upload did not happen yet because I was waiting for Sebastian to release
0.101.4+dfsg-0+deb9u1. This happened today, so I expect to be able to release
the jessie update tomorrow.
faad2:
+ Review my previous work, investigate and prepare patches for a few more
security issues, get them reviewed and merged by upstream. This includes
*a lot* of triage work, non trivial debugging and requesting a CVE number for
a temporary entry from our tracker.
+ The last patches have been reviewed and merged this morning, meaning that I
will be able to release the jessie update in the next days.
Otherwise, the usual triage. I kept an eye on hdf5.
cheers,
Hugo
--
Hugo Lefeuvre (hle)|www.owl.eu.com
RSA4096_ 360B 03B3 BF27 4F4D 7A3F D5E8 14AA 1EB8 A247 3DFD
ed25519_ 37B2 6D38 0B25 B8A2 6B9F 3A65 A36F 5357 5F2D DC4C
signature.asc
Description: PGP signature
Re: xymon vulnerabilities in jessie, stretch and buster
Hi, > > Anyways, 4.3.29 introduced quite a few regressions[0], we should probably > > wait > > for 4.3.30. > > I would neither upload 4.3.29 nor 4.3.30 to Jessie but only the > minimal patch plus the hostname regex regression patch as I do for > Stretch and Buster. Thanks! I have backported your stretch update, currently testing it. > Also someone needs first to verify that the Xymon upstream version in > Jessie (IIRC 4.3.17) is actually vulnerable. Upstream didn't specify > if any version before 4.3.28 is affected, too. I did not reproduce the issue, but the vulnerable code is present. regards, Hugo -- Hugo Lefeuvre (hle)|www.owl.eu.com RSA4096_ 360B 03B3 BF27 4F4D 7A3F D5E8 14AA 1EB8 A247 3DFD ed25519_ 37B2 6D38 0B25 B8A2 6B9F 3A65 A36F 5357 5F2D DC4C signature.asc Description: PGP signature
Re: xymon vulnerabilities in jessie, stretch and buster
Hi, > > These are scheduled via the next 9.10 and 10.1 point releases, but it > > seems > > we missed to mark it as no-dsa yet, I'll fix that in a bit. > > There doesn't appear to be a request for either a buster or stretch update > yet, for the record. Anyways, 4.3.29 introduced quite a few regressions[0], we should probably wait for 4.3.30. regards, Hugo [0] https://lists.xymon.com/archive/2019-August/046643.html -- Hugo Lefeuvre (hle)|www.owl.eu.com RSA4096_ 360B 03B3 BF27 4F4D 7A3F D5E8 14AA 1EB8 A247 3DFD ed25519_ 37B2 6D38 0B25 B8A2 6B9F 3A65 A36F 5357 5F2D DC4C signature.asc Description: PGP signature
Re: xymon vulnerabilities in jessie, stretch and buster
Hi Moritz, > > I see that Moritz and Axel already discussed this on upstream's mailing > > list, > > however the tracker has not been updated yet. Is anybody working on it? If > > not, > > I can take some time to do it. > > These are scheduled via the next 9.10 and 10.1 point releases, but it seems > we missed to mark it as no-dsa yet, I'll fix that in a bit. Are you going to do a bump to 4.3.29 or cherry pick patches? Unless maintainers strongly advise for it I will not bump jessie to 4.3.29, the diff is > 15K lines and I am not confident enough with the codebase to do that. Thanks! cheers, Hugo -- Hugo Lefeuvre (hle)|www.owl.eu.com RSA4096_ 360B 03B3 BF27 4F4D 7A3F D5E8 14AA 1EB8 A247 3DFD ed25519_ 37B2 6D38 0B25 B8A2 6B9F 3A65 A36F 5357 5F2D DC4C signature.asc Description: PGP signature
xymon vulnerabilities in jessie, stretch and buster
Hi,
I just had a look at xymon's vulnerabilities in jessie, stretch and buster.
Upstream claims some of these issues to be exploitable, among others the XSS
vulnerability. I plan to address at least this one in jessie.
I see that Moritz and Axel already discussed this on upstream's mailing list,
however the tracker has not been updated yet. Is anybody working on it? If not,
I can take some time to do it.
Buster and stretch are not far from 4.3.29, so, in case the security team wants
to address these issues, a version bump could maybe be considered? For jessie,
it could be worth inspecting the diff, but there were quite a few releases
between 4.3.17 and 4.3.29... I'm considering to cherry pick relevant changes for
the most important issues.
Christoph and Axel, do you have comments/suggestions regarding this?
regards,
Hugo
--
Hugo Lefeuvre (hle)|www.owl.eu.com
RSA4096_ 360B 03B3 BF27 4F4D 7A3F D5E8 14AA 1EB8 A247 3DFD
ed25519_ 37B2 6D38 0B25 B8A2 6B9F 3A65 A36F 5357 5F2D DC4C
signature.asc
Description: PGP signature
reproducing tika vulnerabilities in jessie/buster
Hi Emmanuel,
I'd like to determine the status of CVE-2019-10094, CVE-2019-10093 and
CVE-2019-10088 in tika[0] for jessie and buster.
I had a look at the source code: so far CVE-2019-10094 and CVE-2019-10088
don't seem to affect jessie. I have doubts concerning CVE-2019-10093.
Being able to reproduce these vulnerabilities would help.
I first thought of passing the reproducers to tika-app.jar, but it looks
like tika-app is not built by the Debian package. The POM is ignored. I
wonder why?
Since you are the Debian maintainer of this package, do you have any
advices which could help me to reproduce these vulnerabilties with the code
from jessie/buster?
thanks for your work!
regards,
Hugo
[0] https://security-tracker.debian.org/tracker/source-package/tika
--
Hugo Lefeuvre (hle)|www.owl.eu.com
RSA4096_ 360B 03B3 BF27 4F4D 7A3F D5E8 14AA 1EB8 A247 3DFD
ed25519_ 37B2 6D38 0B25 B8A2 6B9F 3A65 A36F 5357 5F2D DC4C
signature.asc
Description: PGP signature
Re: security fixes for CVE-2019-10088 and CVE-2019-1009{3,4}
Hi Tim, > Y. You got CVE-2019-10088: > https://github.com/apache/tika/commit/426be73b9e7500fa3d441231fa4e473de34743f6 > > Two other commits you'll want are the following > > CVE-2019-10093: > https://github.com/apache/tika/commit/81c21ab0aac6b3e4102a1a8906c8c7eab6f96dae > > CVE-2019-10094: > https://github.com/apache/tika/commit/c4e63c9be8665cccea8b680c59a6f5cfbc03e0fc Thanks! I was wondering... is there any reason why tika developers don't include CVE information in commit messages? This would ease the work of security teams significantly. regards, Hugo [0] https://tika.apache.org/security.html -- Hugo Lefeuvre (hle)|www.owl.eu.com RSA4096_ 360B 03B3 BF27 4F4D 7A3F D5E8 14AA 1EB8 A247 3DFD ed25519_ 37B2 6D38 0B25 B8A2 6B9F 3A65 A36F 5357 5F2D DC4C signature.asc Description: PGP signature
Re: clamav triage (updated via -updates)
Hi Holger and Moritz, > > What is this -updates mechanism? I might have missed something, does clamav > > have an auto-update mechanism? > > It's what used to be volatile some years ago. ClamAV is only getting updated > via -updates as it can't reasonably be part of a regular stable release; new > malware signatures provided via FreshClam sometimes require new engine > features > so it needs to be kept up with current upstream. It's still present on the > install media, but the idea is that by means of -updates it's ensured that > always the latest version is present without waiting for the next point > release. Thanks your answer. I suppose that buster and stretch will be upgraded to the latest upstream release when the definitive patch will be available for this issue. I will then backport the same changes to jessie. cheers, Hugo -- Hugo Lefeuvre (hle)|www.owl.eu.com RSA4096_ 360B 03B3 BF27 4F4D 7A3F D5E8 14AA 1EB8 A247 3DFD ed25519_ 37B2 6D38 0B25 B8A2 6B9F 3A65 A36F 5357 5F2D DC4C signature.asc Description: PGP signature
clamav triage (updated via -updates)
Hi,
I am taking a look at clamav's zip bomb issue[0] in jessie. This issue is
no-dsa in buster/stretch: "ClamAV is updated via -updates".
What is this -updates mechanism? I might have missed something, does clamav
have an auto-update mechanism?
regards,
Hugo
[0] https://bugs.debian.org/934359
--
Hugo Lefeuvre (hle)|www.owl.eu.com
RSA4096_ 360B 03B3 BF27 4F4D 7A3F D5E8 14AA 1EB8 A247 3DFD
ed25519_ 37B2 6D38 0B25 B8A2 6B9F 3A65 A36F 5357 5F2D DC4C
signature.asc
Description: PGP signature
security fixes for CVE-2019-10088 and CVE-2019-1009{3,4}
Dear tika developers,
I'd like to backport the security fixes for CVE-2019-10088, CVE-2019-10093
and CVE-2019-10094 to older tika releases in Debian.
I had a look at the changelog, the corresponding commit seems to be
https://github.com/apache/tika/commit/426be73b9e7500fa3d441231fa4e473de34743f6
Can anybody confirm? Are there other fixes I should consider applying?
thanks!
regards,
Hugo Lefeuvre (Debian LTS team)
--
Hugo Lefeuvre (hle)|www.owl.eu.com
RSA4096_ 360B 03B3 BF27 4F4D 7A3F D5E8 14AA 1EB8 A247 3DFD
ed25519_ 37B2 6D38 0B25 B8A2 6B9F 3A65 A36F 5357 5F2D DC4C
signature.asc
Description: PGP signature
Re: imagemagick: CVE-2019-13305/CVE-2019-13306
Hi, These issues are similar, both fixed by [0]. Upstream claims to have fixed CVE-2019-13306 via [1] but this is wrong, [1] is reverted by [0]. I took some time to investigate this vulnerability. Unless I am mistaken, this allows for arbitrary stack buffer overflow up to 10 bytes via pixel luma values. My exploitation skills are limited, but this could be an exploitable vulnerability. I think this should be fixed, at least via point release? regards, Hugo [0] https://github.com/ImageMagick/ImageMagick6/commit/5c7fbf9a14fb83c9685ad69d48899f490a37609d [1] https://github.com/ImageMagick/ImageMagick6/commit/cb5ec7d98195aa74d5ed299b38eff2a68122f3fa -- Hugo Lefeuvre (hle)|www.owl.eu.com RSA4096_ 360B 03B3 BF27 4F4D 7A3F D5E8 14AA 1EB8 A247 3DFD ed25519_ 37B2 6D38 0B25 B8A2 6B9F 3A65 A36F 5357 5F2D DC4C signature.asc Description: PGP signature
CVE-2019-12977 analysis
Hi, I had a look at CVE-2019-12977: This allows attackers to manipulate the JP2 compression arguments passed by imagemagick to openjpeg. As long as openjpeg sanitizes its arguments, this issue does not have any security impact. Any useful exploit of this issue requires to chain it with another vulnerability in openjpeg. Also: I suspect that these compression arguments can actually be arbitrarily set by the user, without exploiting any kind of vulnerability. In other words, this issue might be completely irrelevant from a security standpoint because it does not allow the user to do more than what he can already do. regards, Hugo -- Hugo Lefeuvre (hle)|www.owl.eu.com RSA4096_ 360B 03B3 BF27 4F4D 7A3F D5E8 14AA 1EB8 A247 3DFD ed25519_ 37B2 6D38 0B25 B8A2 6B9F 3A65 A36F 5357 5F2D DC4C signature.asc Description: PGP signature
July LTS Report
Hi,
Here is my LTS report for July 2019.
July was -- again -- a very busy month and I could not spend as much time
on LTS and security duties as I wanted to. I was allocated 18.5 hours and
could only spend 9.75 of them in the following tasks:
libsdl2-image, sdl-image1.2:
+ prepare, test and upload a security update for libsdl2-image (DLA-1861-1).
+ prepare, test and upload a security update for sdl-image1.2 (DLA-1865-1).
+ I have also submitted a stretch-pu upload for libsdl2-image (#933218).
imagemagick:
+ triage new issues and start preparing next upload, should happen this
month.
misc:
+ various triage in the tracker.
+ wavpack: take a look at current issues, answer Brian's e-mail.
+ hdf5: take stock of the situation, prepare plans for next update.
I should be able to use up the remaining hours in august.
cheers,
Hugo
--
Hugo Lefeuvre (hle)|www.owl.eu.com
RSA4096_ 360B 03B3 BF27 4F4D 7A3F D5E8 14AA 1EB8 A247 3DFD
ed25519_ 37B2 6D38 0B25 B8A2 6B9F 3A65 A36F 5357 5F2D DC4C
signature.asc
Description: PGP signature
Re: [SECURITY] [DLA 1865-1] sdl-image1.2 security update
> I don't think it's explicitly documented; I inferred it from these > rules: > > 1. Corrections should be sent to the same recipients as the original > incorrect information. > 2. All messages sent to debian-lts-announce about package updates > should be numbered DLAs. > 3. DLAs that are related to prior DLAs should use the same first part > and an incremented second part. Sounds reasonable. Thanks! regards, Hugo -- Hugo Lefeuvre (hle)|www.owl.eu.com RSA4096_ 360B 03B3 BF27 4F4D 7A3F D5E8 14AA 1EB8 A247 3DFD ed25519_ 37B2 6D38 0B25 B8A2 6B9F 3A65 A36F 5357 5F2D DC4C signature.asc Description: PGP signature
Re: [SECURITY] [DLA 1865-1] sdl-image1.2 security update
Hi Ben, > > > For Debian 8 "Jessie", these problems have been fixed in version > > > 1.2.12-5+deb9u2. > > > > Typo: version number is 1.2.12-5+deb8u2, not 1.2.12-5+deb9u2. > > The proper way to make such a correction is to issue a -2 advisory with > the correct information and a note about what changed. Thanks, I wasn't aware of this. I can't find any information about it in our documentation, did I miss something? (just in case: this is not a regression, just a typo in the advisory) regards, Hugo -- Hugo Lefeuvre (hle)|www.owl.eu.com RSA4096_ 360B 03B3 BF27 4F4D 7A3F D5E8 14AA 1EB8 A247 3DFD ed25519_ 37B2 6D38 0B25 B8A2 6B9F 3A65 A36F 5357 5F2D DC4C signature.asc Description: PGP signature
Re: [SECURITY] [DLA 1865-1] sdl-image1.2 security update
On Sat, Jul 27, 2019 at 03:30:14PM -0300, Hugo Lefeuvre wrote: > Package: sdl-image1.2 > Version: 1.2.12-5+deb9u2 > CVE ID : CVE-2018-3977 CVE-2019-5051 CVE-2019-5052 CVE-2019-7635 > CVE-2019-12216 CVE-2019-12217 CVE-2019-12218 CVE-2019-12219 > CVE-2019-12220 CVE-2019-12221 CVE-2019-1 > > [...] > > For Debian 8 "Jessie", these problems have been fixed in version > 1.2.12-5+deb9u2. Typo: version number is 1.2.12-5+deb8u2, not 1.2.12-5+deb9u2. -- Hugo Lefeuvre (hle)|www.owl.eu.com RSA4096_ 360B 03B3 BF27 4F4D 7A3F D5E8 14AA 1EB8 A247 3DFD ed25519_ 37B2 6D38 0B25 B8A2 6B9F 3A65 A36F 5357 5F2D DC4C signature.asc Description: PGP signature
Re: minor issues (wavpack)
Hi Brian, my two cents > - CVE-2019-1010315: divide by zero This can only be used to trigger DoS, I don't think it is relevant in the case of wavpack. I would triage it no-dsa. > - CVE-2019-1010317: use of uninitialized memory. > - CVE-2019-1010319: use of uninitialized memory. > > All three issues have been marked no-DSA by the security team. Does that > mean we should do the same thing? I didn't have a very detailed look at these two, but in general this kind of issues are hard to exploit. Getting rce with these seems unlikely to me, but I am not a skilled attacker. I guess this is why the security team triaged them no-dsa. Now, the patches seem fairly easy to review and there's little potential for regressions. So, in the LTS case, I'd take a closer look at them and probably mark them postponed. If we've got time, we can maybe ship these patches in a future update. cheers, Hugo -- Hugo Lefeuvre (hle)|www.owl.eu.com RSA4096_ 360B 03B3 BF27 4F4D 7A3F D5E8 14AA 1EB8 A247 3DFD ed25519_ 37B2 6D38 0B25 B8A2 6B9F 3A65 A36F 5357 5F2D DC4C signature.asc Description: PGP signature
Re: libsdl2-image security issues in testing
Hi Felix, (CC-ing #932754 which tracks this issue) > > I have prepared a jessie (LTS) update addressing libsdl2-image's current > > security issues. I will coordinate with the security team to possibly fix > > them in a future stretch/buster point update. > > > > Are you planning to address these issues in testing? Packaging upstream's > > latest 2.0.5 release should be sufficient, but they can also be addressed > > with more targeted fixes. > > > > I can provide some help if needed. > > Thanks for your work! > > I'm preparing a 2.0.5 upload right now. Great, thanks! > As far as I can tell all CVEs in the tracker are fixed with 2.0.5. > Do you agree? Exactly. By the way, I had a second look and it appears that CVE-2019-5051 was also fixed by the jessie LTS upload. CVE-2019-5051 is also a member of the CVE-2019-12221 family, and is therefore fixed by [0]. cheers, Hugo [0] https://hg.libsdl.org/SDL_image/rev/e7e9786a1a34 -- Hugo Lefeuvre (hle)|www.owl.eu.com RSA4096_ 360B 03B3 BF27 4F4D 7A3F D5E8 14AA 1EB8 A247 3DFD ed25519_ 37B2 6D38 0B25 B8A2 6B9F 3A65 A36F 5357 5F2D DC4C signature.asc Description: PGP signature
libsdl2-image security issues in testing
Dear libsdl2-image maintainers,
I have prepared a jessie (LTS) update addressing libsdl2-image's current
security issues. I will coordinate with the security team to possibly fix
them in a future stretch/buster point update.
Are you planning to address these issues in testing? Packaging upstream's
latest 2.0.5 release should be sufficient, but they can also be addressed
with more targeted fixes.
I can provide some help if needed.
Thanks for your work!
cheers,
Hugo
--
Hugo Lefeuvre (hle)|www.owl.eu.com
RSA4096_ 360B 03B3 BF27 4F4D 7A3F D5E8 14AA 1EB8 A247 3DFD
ed25519_ 37B2 6D38 0B25 B8A2 6B9F 3A65 A36F 5357 5F2D DC4C
signature.asc
Description: PGP signature
June (E)LTS Report
Hi, Here are my LTS and ELTS reports for June 2019. = Debian LTS report Personal tasks kept me away from my Debian activities in june, which explains the very low amount of hours spent this month. I was allocated 17 hours and could only spend 4.25 of them in the following tasks: graphicsmagick: + remaining work from may on DLA-1795-1. libsdl2-image: sdl-image1.2: + remaining work from may on CVE-2019-12221, CVE-2019-12219, CVE-2019-12220, CVE-2019-1. Patches have been merged by upstream and are now ready to upload. I will update dla-needed. The remaining hours will be returned to the pool. == Debian ELTS report I was allocated 15 hours. I did not spend any of them (I already returned them to the pool on June, 18th). cheers, Hugo -- Hugo Lefeuvre (hle)|www.owl.eu.com RSA4096_ 360B 03B3 BF27 4F4D 7A3F D5E8 14AA 1EB8 A247 3DFD ed25519_ 37B2 6D38 0B25 B8A2 6B9F 3A65 A36F 5357 5F2D DC4C signature.asc Description: PGP signature
May (E)LTS Report
Hi, Here are my LTS and ELTS reports for May 2019. = Debian LTS report I was allocated 18 hours. I have spent all of them in the following tasks: hdf5: + Continued my triage work. I initially planned to do a first upload this month, but was not able to do this within my assigned time. Contacted upstream regarding CVE-2018-17432. First upload planned for june. jinja2: + I have continued my triage work regarding CVE-2019-10906 and CVE-2016-10745. After some discussion with the security team we decided to mark it no-dsa. liblivemedia: + Raised upstream's attention on CVE-2019-7732 and CVE-2019-7733. This resulted in upstream rejecting CVE-2019-7732 and patching CVE-2019-7733. I finally marked CVE-2019-7733 no-dsa. faad2: + Lots of triage work after last update. + Prepare patches for CVE-2018-20196 and submit them for upstream review. Will be uploaded once merged, this month. See https://github.com/knik0/faad2/pull/36 + prepare, test and update a security update addressing CVE-2018-20362, CVE-2018-20198, CVE-2018-20197 and CVE-2018-20194 (DLA-1791-1). imagemagick: + First triage, contact Markus and Roberto concerning their previous work on the matter. + Prepare a security update addressing CVE-2019-9956, CVE-2019-11598, CVE-2019-11597 and CVE-2019-10650 (DLA 1785-1). Backporting these patches was a lot of work. I discovered multiple issues in upstream's patches and struggled to explain why the CVE-2019-11597 pocs were still affecting jessie after applying upstream's patches. It turned out that the upstream's initial patches were insufficient... graphicsmagick: + prepare, test and upload a security update addressing CVE-2019-11506, CVE-2019-11505, CVE-2019-11474 and CVE-2019-11473 (DLA-1795-1). + find minor regressions in 1.3.20-3+deb8u6. Fixed them in DLA-1795-1. wireshark: + prepare, test and upload a security update addressing CVE-2019-10903, CVE-2019-10901, CVE-2019-10899, CVE-2019-10895 and CVE-2019-10894 (DLA 1802-1). sysdig: + start to work on CVE-2019-8339, but did not have enough time this month to fulfill my investigations. libsdl2-image: sdl-image1.2: + coordinate work with ELTS on CVE-2019-12221, CVE-2019-12219, CVE-2019-12220, CVE-2019-1. See ELTS report. misc: + various triage, see tracker's logs. == Debian ELTS report I was allocated 15 hours. I have spent all of them in the following tasks: wireshark: + prepare, test and upload a security update addressing CVE-2019-10895 and CVE-2019-10894 (ELA-118-1). Backporting patches took a lot of time, but in the end it was worth it because this work could be uploaded to both wheezy and jessie. + prepare, test and upload a second update fixing CVE-2019-12295 and older vulnerabilities: CVE-2017-13767, CVE-2017-9345, CVE-2017-9352 and CVE-2017-9617 (ELA-126-1). + fix inconsistencies in ELA-75-1. tomcat7: + prepare, test and upload a security update addressing CVE-2019-0221 (ELA-124-1). modsecurity-crs: + Investigate and get in touch with upstream regarding fixes. Finally mark no-dsa, given that the impact on reverse dependencies is highly negligible and patches rather complex. libsdl1.2: + investigate CVE-2019-12221, CVE-2019-12219, CVE-2019-12220 and CVE-2019-1: should be ignored because they actually affects libsdl2-image and sdl-image1.2, not libsdl2/libsdl1.2. The -image part of the SDL library is EOL. suricata: + Perform proper triage for currently open issues. Prepare and test a security update addressing CVE-2019-10053 (not uploaded yet, but should be done by tomorrow). misc: + various triage, see tracker's logs. cheers, Hugo -- Hugo Lefeuvre (hle)|www.owl.eu.com RSA4096_ 360B 03B3 BF27 4F4D 7A3F D5E8 14AA 1EB8 A247 3DFD ed25519_ 37B2 6D38 0B25 B8A2 6B9F 3A65 A36F 5357 5F2D DC4C signature.asc Description: PGP signature
Re: failed armel build of wireshark 1.12.1+g01b65bf-4+deb8u19
> Given back.
Thanks Emilio!
No idea what happened (hardware issue?), anyways, build succeeded.
cheers,
Hugo
--
Hugo Lefeuvre (hle)|www.owl.eu.com
RSA4096_ 360B 03B3 BF27 4F4D 7A3F D5E8 14AA 1EB8 A247 3DFD
ed25519_ 37B2 6D38 0B25 B8A2 6B9F 3A65 A36F 5357 5F2D DC4C
signature.asc
Description: PGP signature
failed armel build of wireshark 1.12.1+g01b65bf-4+deb8u19
Hi, Apparently, wireshark 1.12.1+g01b65bf-4+deb8u19 failed to build on armel. I have absolutely no idea of what happened. At first glance it looks like tar segfaulted[0] :-) Is it possible to restart the build for armel? cheers, Hugo [0] https://buildd.debian.org/status/package.php?p=wireshark&suite=jessie-security -- Hugo Lefeuvre (hle)|www.owl.eu.com RSA4096_ 360B 03B3 BF27 4F4D 7A3F D5E8 14AA 1EB8 A247 3DFD ed25519_ 37B2 6D38 0B25 B8A2 6B9F 3A65 A36F 5357 5F2D DC4C signature.asc Description: PGP signature
Re: CVE-2019-12221 affects libsdl2-image/sdl-image1.2, not libsdl2/libsdl1.2
> Btw, if you did as well already check the respective other libsdl*
> CVEs which were noch clear at the initial time and carry thus the same
> TODO and the source tracking is correct, then please do remove there
> as well the TODO item.
Sure! I'm planning to investigate these issues as well, although I didn't
have time to do it yet. I will update the tracker entries then.
cheers,
Hugo
--
Hugo Lefeuvre (hle)|www.owl.eu.com
RSA4096_ 360B 03B3 BF27 4F4D 7A3F D5E8 14AA 1EB8 A247 3DFD
ed25519_ 37B2 6D38 0B25 B8A2 6B9F 3A65 A36F 5357 5F2D DC4C
signature.asc
Description: PGP signature
Re: CVE-2019-12221 affects libsdl2-image/sdl-image1.2, not libsdl2/libsdl1.2
Hi Salvatore, > When the CVE first appeared it was not yet clear where exactly the > vulnerabilities lie, thus we kept the TODO as per > > TODO: check details and correct vulnerability location > > Now that you apparently found the root cause and followed up upstream > in the bugzilla, right thing would be to replace the source package > tracking entries to the correct source. > So basically replace tracking of slibsdl2 and libsdl1.2 with > libsdl2-image and sdl-image1.2 instead. I see that you already did it, thanks! :) cheers, Hugo -- Hugo Lefeuvre (hle)|www.owl.eu.com RSA4096_ 360B 03B3 BF27 4F4D 7A3F D5E8 14AA 1EB8 A247 3DFD ed25519_ 37B2 6D38 0B25 B8A2 6B9F 3A65 A36F 5357 5F2D DC4C signature.asc Description: PGP signature
CVE-2019-12221 affects libsdl2-image/sdl-image1.2, not libsdl2/libsdl1.2
Hi, I investigated CVE-2019-12221[0] and found out that the issue lies in the libsdl2-image/sdl-image1.2 codebase, not libsdl2/libsdl1.2. I have temporarily added a NOTE to the tracker because I was not sure of how to handle this[1]. Should I simply replace [stretch] - libsdl2 by [stretch] - libsdl2-image and same for libsdl1.2? thanks, Hugo [0] https://bugzilla.libsdl.org/show_bug.cgi?id=4628 [1] https://salsa.debian.org/security-tracker-team/security-tracker/commit/39f9e891a4b37 -- Hugo Lefeuvre (hle)|www.owl.eu.com RSA4096_ 360B 03B3 BF27 4F4D 7A3F D5E8 14AA 1EB8 A247 3DFD ed25519_ 37B2 6D38 0B25 B8A2 6B9F 3A65 A36F 5357 5F2D DC4C signature.asc Description: PGP signature
Re: dla-needed/imagemagick entry
Hi Markus,
> I'm fine with uploading tomorrow. Just send me your debdiff and I will
> incorporate your changes.
You can find the debdiff for CVE-2019-9956, CVE-2019-11598, CVE-2019-11597
and CVE-2019-10650 in attachement, along with appropriate DLA text entries.
I briefly thought of adding fixes for other recent CVEs, but given the
pain it was to backport CVE-2019-11598 and CVE-2019-11597 (multiple issues
in the patches, required extensive testing), I though it would maybe be
better to avoid very large uploads and keep them for future DLAs.
cheers,
Hugo
--
Hugo Lefeuvre (hle)|www.owl.eu.com
RSA4096_ 360B 03B3 BF27 4F4D 7A3F D5E8 14AA 1EB8 A247 3DFD
ed25519_ 37B2 6D38 0B25 B8A2 6B9F 3A65 A36F 5357 5F2D DC4C
diff -Nru imagemagick-6.8.9.9/debian/changelog
imagemagick-6.8.9.9/debian/changelog
--- imagemagick-6.8.9.9/debian/changelog2018-11-11 17:03:02.0
+0100
+++ imagemagick-6.8.9.9/debian/changelog2019-05-05 13:46:47.0
+0200
@@ -1,3 +1,17 @@
+imagemagick (8:6.8.9.9-5+deb8u16) jessie-security; urgency=medium
+
+ * Non-maintainer upload by the LTS Security Team.
+ * CVE-2019-9956: stack-based buffer overflow in PopHexPixel, allows DoS or
+remote code execution (Closes: #925395).
+ * CVE-2019-11598: heap-based buffer over-read in WritePNMImage, allows DoS
+or information disclosure (Closes: #928206).
+ * CVE-2019-11597: heap-based buffer over-read in WriteTIFFImage, allows Dos
+or information disclosure (Closes: #928207).
+ * CVE-2019-10650: heap-based buffer over-read in WriteTIFFImage, allows DoS
+or information disclosure (Closes: #926091).
+
+ -- Hugo Lefeuvre Sun, 05 May 2019 13:46:47 +0200
+
imagemagick (8:6.8.9.9-5+deb8u15) jessie-security; urgency=high
* Non-maintainer upload by the LTS Team.
diff -Nru imagemagick-6.8.9.9/debian/patches/0283-CVE-2019-9956.patch
imagemagick-6.8.9.9/debian/patches/0283-CVE-2019-9956.patch
--- imagemagick-6.8.9.9/debian/patches/0283-CVE-2019-9956.patch 1970-01-01
01:00:00.0 +0100
+++ imagemagick-6.8.9.9/debian/patches/0283-CVE-2019-9956.patch 2019-05-05
13:46:47.0 +0200
@@ -0,0 +1,22 @@
+Subject: fix stack buffer overflow in PopHexPixel
+Author: Cristy
+Origin: upstream,
https://github.com/ImageMagick/ImageMagick6/commit/90401e430840c5ff31ad870f4370bbda1318ac94
+Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=925395
+--- a/coders/ps.c 2019-05-05 13:46:32.0 +0200
b/coders/ps.c 2019-05-11 08:03:04.238884795 +0200
+@@ -2206,8 +2206,13 @@
+ p++;
+ }
+ q=PopHexPixel(hex_digits,(size_t) index,q);
+-q=PopHexPixel(hex_digits,(size_t)
+- MagickMin(length,0xff),q);
++q=PopHexPixel(hex_digits,(size_t) MagickMin(length,0xff),q);
++if ((q-pixels+6) >= 80)
++ {
++*q++='\n';
++(void) WriteBlob(image,q-pixels,pixels);
++q=pixels;
++ }
+ if (image->previous == (Image *) NULL)
+ {
+ status=SetImageProgress(image,SaveImageTag,
diff -Nru imagemagick-6.8.9.9/debian/patches/0284-CVE-2019-10650.patch
imagemagick-6.8.9.9/debian/patches/0284-CVE-2019-10650.patch
--- imagemagick-6.8.9.9/debian/patches/0284-CVE-2019-10650.patch
1970-01-01 01:00:00.0 +0100
+++ imagemagick-6.8.9.9/debian/patches/0284-CVE-2019-10650.patch
2019-05-05 13:46:47.0 +0200
@@ -0,0 +1,19 @@
+Subject: fix heap-buffer-overflow in WriteTIFFImage
+Author: Cristy
+Origin: upstream,
https://github.com/ImageMagick/ImageMagick6/commit/4800ae0dabdb3012f82820af946060c3ca9fdb87
+
https://github.com/ImageMagick/ImageMagick6/commit/d8d844c6f23f4d90d8fe893fe9225dd78fc1e6ef
+Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=926091
+--- a/coders/tiff.c2019-05-11 08:11:49.834745216 +0200
b/coders/tiff.c2019-05-11 08:15:36.645306260 +0200
+@@ -2946,6 +2946,11 @@
+ (void) TIFFSetErrorHandler(error_handler);
+ return(MagickFalse);
+ }
++ if (image->exception.severity > ErrorException)
++{
++ TIFFClose(tiff);
++ return(MagickFalse);
++}
+ scene=0;
+ debug=IsEventLogging();
+ (void) debug;
diff -Nru imagemagick-6.8.9.9/debian/patches/0285-CVE-2019-11598.patch
imagemagick-6.8.9.9/debian/patches/0285-CVE-2019-11598.patch
--- imagemagick-6.8.9.9/debian/patches/0285-CVE-2019-11598.patch
1970-01-01 01:00:00.0 +0100
+++ imagemagick-6.8.9.9/debian/patches/0285-CVE-2019-11598.patch
2019-05-05 13:46:47.0 +0200
@@ -0,0 +1,97 @@
+Subject: fix heap-buffer-overflow in SetGrayscaleImage()
+ This patch addresses a heap-buffer-overflow in SetGrayscaleImage(),
+ known as CVE-2019-11598.
+ .
+ The original upstream patch also included a few minor modifications
+ addressing
Re: dla-needed/imagemagick entry
> Great! I have found potential issues in upstream's patch for CVE-2019-11598
> and would maybe wait a little bit for his answer (more info in dla-needed).
>
> If he takes too long, we can just as well remove this patch from the update
> and mark it postponed until upstream addresses these issues.
Upstream fixed these issues yesterday, I will update my work and send it to
you. Thanks!
Hugo
--
Hugo Lefeuvre (hle)|www.owl.eu.com
RSA4096_ 360B 03B3 BF27 4F4D 7A3F D5E8 14AA 1EB8 A247 3DFD
ed25519_ 37B2 6D38 0B25 B8A2 6B9F 3A65 A36F 5357 5F2D DC4C
signature.asc
Description: PGP signature
Re: dla-needed/imagemagick entry
> > I have prepared an update addressing CVE-2019-9956, CVE-2019-10650, > > CVE-2019-11598 and CVE-2019-11597. I'm currently testing it. Still OK to > > upload during the week-end? > > I'm fine with uploading tomorrow. Just send me your debdiff and I will > incorporate your changes. Great! I have found potential issues in upstream's patch for CVE-2019-11598 and would maybe wait a little bit for his answer (more info in dla-needed). If he takes too long, we can just as well remove this patch from the update and mark it postponed until upstream addresses these issues. cheers, Hugo -- Hugo Lefeuvre (hle)|www.owl.eu.com RSA4096_ 360B 03B3 BF27 4F4D 7A3F D5E8 14AA 1EB8 A247 3DFD ed25519_ 37B2 6D38 0B25 B8A2 6B9F 3A65 A36F 5357 5F2D DC4C signature.asc Description: PGP signature
Re: dla-needed/imagemagick entry
Hi Markus, > > Good idea. I plan to work on CVE-2019-9956, CVE-2019-10650 and possibly > > CVE-2019-11598. Do you think an upload ~ next week-end would be feasible > > for you? > > Sure, that should be feasible. I have prepared an update addressing CVE-2019-9956, CVE-2019-10650, CVE-2019-11598 and CVE-2019-11597. I'm currently testing it. Still OK to upload during the week-end? cheers, Hugo -- Hugo Lefeuvre (hle)|www.owl.eu.com RSA4096_ 360B 03B3 BF27 4F4D 7A3F D5E8 14AA 1EB8 A247 3DFD ed25519_ 37B2 6D38 0B25 B8A2 6B9F 3A65 A36F 5357 5F2D DC4C signature.asc Description: PGP signature
dla-needed/imagemagick entry
Hi Markus and Roberto,
I just had a look at imagemagick in jessie and did some quick triage.
I saw the following notes in dla-needed:
NOTE: 20190408: Still waiting on security team response to inquiries
from (apo) and (roberto)
Did you CC debian-lts? I can't find the e-mail you're referring to :)
NOTE: 20181227: We should address the many open issues in imagemagick
either by patching them separetely as we did in Wheezy or by updating
to a new upstream version like the security team did with Graphicsmagick
in Stretch. (apo)
I think the security team opted for targeted fixes in the imagemagick case,
at least for CVE-2019-9956 (claims remote code execution) and
CVE-2019-10650, which appear to be the most important ones.
I'd also like to fix CVE-2019-11598, but that would be pretty much it. The
rest can be ignored, IMO.
Backporting targeted fixes should be feasible, even if the code changed
quite a bit. I'm not sure upgrading to a whole upstream release is worth
it.
Any comments?
Thanks!
cheers,
Hugo
--
Hugo Lefeuvre (hle)|www.owl.eu.com
RSA4096_ 360B 03B3 BF27 4F4D 7A3F D5E8 14AA 1EB8 A247 3DFD
ed25519_ 37B2 6D38 0B25 B8A2 6B9F 3A65 A36F 5357 5F2D DC4C
signature.asc
Description: PGP signature
Re: dla-needed/imagemagick entry
Hi Markus, > We contacted the security team directly without CCing the lts mailing > list. However they didn't reply to us. OK, Roberto forwarded the discussion to me. > > I think the security team opted for targeted fixes in the imagemagick case, > > at least for CVE-2019-9956 (claims remote code execution) and > > CVE-2019-10650, which appear to be the most important ones. > > > > I'd also like to fix CVE-2019-11598, but that would be pretty much it. The > > rest can be ignored, IMO. > > > > Backporting targeted fixes should be feasible, even if the code changed > > quite a bit. I'm not sure upgrading to a whole upstream release is worth > > it. > > > > Any comments? > > I was about to claim imagemagick in the next days and wanted to do some > targeted fixes. My idea was to forward port the fixes we did in Wheezy > and to fix everything else that seems in need of fixing. I haven't > determined the severity of all no-dsa CVE yet. We could combine our work > like I did with Mike and libav. Good idea. I plan to work on CVE-2019-9956, CVE-2019-10650 and possibly CVE-2019-11598. Do you think an upload ~ next week-end would be feasible for you? cheers, Hugo -- Hugo Lefeuvre (hle)|www.owl.eu.com RSA4096_ 360B 03B3 BF27 4F4D 7A3F D5E8 14AA 1EB8 A247 3DFD ed25519_ 37B2 6D38 0B25 B8A2 6B9F 3A65 A36F 5357 5F2D DC4C signature.asc Description: PGP signature
Re: dla-needed/imagemagick entry
Hi Roberto, > > Did you CC debian-lts? I can't find the e-mail you're referring to :) > > > I did not. In a few minutes I will bounce you the message from that > discussion (there are 5 or 6). I won't bounce them to the list, though, > as I suspect they will get flagged as spam. Thanks for the prompt answer! > > NOTE: 20181227: We should address the many open issues in imagemagick > > either by patching them separetely as we did in Wheezy or by updating > > to a new upstream version like the security team did with Graphicsmagick > > in Stretch. (apo) > > > > I think the security team opted for targeted fixes in the imagemagick case, > > at least for CVE-2019-9956 (claims remote code execution) and > > CVE-2019-10650, which appear to be the most important ones. > > > > I'd also like to fix CVE-2019-11598, but that would be pretty much it. The > > rest can be ignored, IMO. > > > > Backporting targeted fixes should be feasible, even if the code changed > > quite a bit. I'm not sure upgrading to a whole upstream release is worth > > it. > > > > Any comments? > > > That all makes sense. I did not do any work on backporting fixes, apart > from making an attempt to build the latest upstream from sid in jessie. > Since the backport idea did not go anywhere, you should be able to pick > up from where the current state is in jessie. Great, I will coordinate with Markus to provide targeted fixes then. Thanks! cheers, Hugo -- Hugo Lefeuvre (hle)|www.owl.eu.com RSA4096_ 360B 03B3 BF27 4F4D 7A3F D5E8 14AA 1EB8 A247 3DFD ed25519_ 37B2 6D38 0B25 B8A2 6B9F 3A65 A36F 5357 5F2D DC4C signature.asc Description: PGP signature
Re: jinja2 update for CVE-2019-10906/CVE-2016-10745
Hi Moritz, > I've never used that myself either, but reading up on the documentation > it's so full of caveats that I doubt these are really severe issues. Unless > someone has credible clams of the contrary I'm inclined to mark these as > no-dsa for stretch. Thanks. We'll go for no-dsa in jessie as well. I see you have marked CVE-2016-10745 no-dsa in stretch but not CVE-2019-10906. Fixing CVE-2019-10906 without CVE-2016-10745 does not make much sense to me, so I assumed it was oversight and marked CVE-2019-10906 no-dsa in stretch as well. cheers, Hugo -- Hugo Lefeuvre (hle)|www.owl.eu.com RSA4096_ 360B 03B3 BF27 4F4D 7A3F D5E8 14AA 1EB8 A247 3DFD ed25519_ 37B2 6D38 0B25 B8A2 6B9F 3A65 A36F 5357 5F2D DC4C signature.asc Description: PGP signature
Re: April (E)LTS Report
> == > Debian ELTS report > > I was allocated 9 hours. I have spent all of them in the following > tasks: > > suricata: > > + Analyse CVE-2018-10244, CVE-2018-10243 and CVE-2018-10242, not-affected > in wheezy. > > wireshark: > > + Analyse CVE-2019-10902 and CVE-2019-10896, not-affected in wheezy. > > Reproduce CVE-2019-10903, CVE-2019-10901 and CVE-2019-10899. Prepare, > test and upload a security update addressing these issues (ELA-106-1). missing: I'm preparing a second upload addressing the remaining wireshark CVEs, should be uploaded by next month. -- Hugo Lefeuvre (hle)|www.owl.eu.com RSA4096_ 360B 03B3 BF27 4F4D 7A3F D5E8 14AA 1EB8 A247 3DFD ed25519_ 37B2 6D38 0B25 B8A2 6B9F 3A65 A36F 5357 5F2D DC4C signature.asc Description: PGP signature
April (E)LTS Report
Hi, Here are my LTS and ELTS reports for April 2019. = Debian LTS report I was allocated 17.25 hours. I have spent all of them in the following tasks: hdf5: + Triage security backlog. Reproduce issues and coordinate with upstream to get rid of our huge undetermined backlog (35+ issues). faad2: + Continue to work on my patch for CVE-2018-20362, coordinate to get it reviewed and merged upstream. Involved a lot of (painful) research in ISO/IEC 13818-7:2006. + Provide in depth analysis for CVE-2018-19887 and prepare a patch. Coordinate to get it reviewed and merged upstream. Involved a lot of research in ISO/IEC 14496-3:2001. (See upstream bug reports for detailed information.) jinja2: + Analyse CVE-2019-10906, develop a POC to assess vulnerability and reproduce on all suites. Find related patches and coordinate with security team and maintainer for update. Ongoing work. suricata: + Prepare a security update addressing CVE-2018-10243 and CVE-2018-10242, test and upload it (DLA-1751-1). Analyse CVE-2018-10244 and mark it not-affected in jessie. misc: + CVE triage work for, among others, libvirt, systemd. + help Markus diagnose graphicsmagik problems with failing testsuite, resulting in jasper regression update later. == Debian ELTS report I was allocated 9 hours. I have spent all of them in the following tasks: suricata: + Analyse CVE-2018-10244, CVE-2018-10243 and CVE-2018-10242, not-affected in wheezy. wireshark: + Analyse CVE-2019-10902 and CVE-2019-10896, not-affected in wheezy. Reproduce CVE-2019-10903, CVE-2019-10901 and CVE-2019-10899. Prepare, test and upload a security update addressing these issues (ELA-106-1). libvirt: + Analyse CVE-2019-3886 and mark it not-affected in wheezy. ncurses: + CVE-2018-19217 analysis and triage. Discussion with Sylvain about not-affected status. libxslt: + Triage CVE-2019-11068, prepare, test and upload a security update addressing this vulnerability (ELA-107-1). systemd: + Analyse CVE-2019-9619 and CVE-2019-3842 and get in coordinate with Mike Gabriel for update. misc: + CVE triage Early report this month. I was allocated less LTS hours than last month and spent a lot of time on faad2 patches, hdf5 and jinja2 triage. The number of released DLAs is low (only one in total), but I have four pending (wireshark, hdf5, faad2 waiting for more patches, and jinja2 for answer from secteam). Concerning ELTS, the number of updates was limited to two. Testing the wireshark update was longer than expected and releasing binaries for both amd64 and i386 has its overhead. cheers, Hugo -- Hugo Lefeuvre (hle)|www.owl.eu.com RSA4096_ 360B 03B3 BF27 4F4D 7A3F D5E8 14AA 1EB8 A247 3DFD ed25519_ 37B2 6D38 0B25 B8A2 6B9F 3A65 A36F 5357 5F2D DC4C signature.asc Description: PGP signature
jinja2 update for CVE-2019-10906/CVE-2016-10745
Dear Piotr, security team,
I am currently working on CVE-2019-10906 and CVE-2016-10745, trying to
decide if preparing an LTS upload for these issues is worth the trouble.
These issues seem to absolutely break the jinja2 sandbox, so if sandboxes
are really used, then we should definitely fix them.
Otherwise I'd consider marking this no-dsa. Patches are not that small.
(good point though, there are unit tests)
I have never used jinja2 sanboxes despite being a jinja2 user for quite a
while, so I have difficulties asserting the severity of these issues.
Piotr, do you have any feedback on this?
Anyways, it only makes sense to me to fix this in Jessie if I also prepare
a stretch update at the same time.
cheers,
Hugo
--
Hugo Lefeuvre (hle)|www.owl.eu.com
RSA4096_ 360B 03B3 BF27 4F4D 7A3F D5E8 14AA 1EB8 A247 3DFD
ed25519_ 37B2 6D38 0B25 B8A2 6B9F 3A65 A36F 5357 5F2D DC4C
signature.asc
Description: PGP signature
Re: LTS, no-dsa reasoning and sponsored packages
Hi Ingo, > labeling it "minor issues" when the real reason is "sponsors needed" > sounds wrong to me. > > I'd say "minor issues" is right for minor issues. And "sponsors needed" > is a legitimate, helpful additional information. > > It seems to me, that it's not uncommon to Debian to search for a sponsor > of a package: > https://mentors.debian.net/sponsors When we speak about sponsors in this context, we mean the "contributing companies and organizations", the entities funding the Debian LTS project[0], not mentors from the package sponsoring process. Yet another reason to not use "sponsoring" related arguments in the tracker? [0] https://wiki.debian.org/LTS/Funding -- Hugo Lefeuvre (hle)|www.owl.eu.com RSA4096_ 360B 03B3 BF27 4F4D 7A3F D5E8 14AA 1EB8 A247 3DFD ed25519_ 37B2 6D38 0B25 B8A2 6B9F 3A65 A36F 5357 5F2D DC4C signature.asc Description: PGP signature
Re: LTS, no-dsa reasoning and sponsored packages
> If LTS is meant as Debian project, then I would suggest not to start > to use those formulations, which I think are fine for ELTS, which is a > dedicated project not on Debian directly. Saying something is not DSA > worthy or is going to be ignored, because it's not used by a LTS > sponsor will give a signal to others that indeed, Debian LTS is not a > generic Debian project. ...not to mention that "Not used by any sponsor" is only true at a moment t. Not necessarily at t+1. Sponsors might use new packages, new sponsors might come or some might leave. Not sure we want to introduce such uncertain information in the tracker anyways. -- Hugo Lefeuvre (hle)|www.owl.eu.com RSA4096_ 360B 03B3 BF27 4F4D 7A3F D5E8 14AA 1EB8 A247 3DFD ed25519_ 37B2 6D38 0B25 B8A2 6B9F 3A65 A36F 5357 5F2D DC4C signature.asc Description: PGP signature
Re: (semi-)automatic unclaim of packages with more than 2 weeks of inactivity
> > I've done this again and am considering (in general) to not write these > > mails > > anymore. Please speak up if you think these mails are useful (or could > > be made more useful.) > > I think they are useful, though according to the wiki page they are part > of the front-desk duties. I also find them useful. -- Hugo Lefeuvre (hle)|www.owl.eu.com RSA4096_ 360B 03B3 BF27 4F4D 7A3F D5E8 14AA 1EB8 A247 3DFD ed25519_ 37B2 6D38 0B25 B8A2 6B9F 3A65 A36F 5357 5F2D DC4C signature.asc Description: PGP signature
Re: CVE-2019-10906 - jinja sandbox escape poc
> This should help confirming vulnerability in other suites.
2.7.3-1 and all later releases affected. In addition, both 2.7.3-1 and
2.8-1 are affected by the previous str.format issue[0].
[0] https://palletsprojects.com/blog/jinja-281-released/
--
Hugo Lefeuvre (hle)|www.owl.eu.com
RSA4096_ 360B 03B3 BF27 4F4D 7A3F D5E8 14AA 1EB8 A247 3DFD
ed25519_ 37B2 6D38 0B25 B8A2 6B9F 3A65 A36F 5357 5F2D DC4C
signature.asc
Description: PGP signature
CVE-2019-10906 - jinja sandbox escape poc
Hi,
I'm working on a potential jinja2 Debian LTS security update. Here is a
proof of concept which allows to easily reproduce the issue. This should
help confirming vulnerability in other suites.
>>> from jinja2.sandbox import SandboxedEnvironment
>>> env = SandboxedEnvironment()
>>> config = {'SECRET_KEY': '12345'}
>>> class User(object):
... def __init__(self, name):
... self.name = name
...
>>> t = env.from_string('{{
>>> "{x.__class__.__init__.__globals__[config]}".format_map(dic) }}')
>>> t.render(dic={"x": User('joe')})
"{'SECRET_KEY': '12345'}"
Expected behaviour would be jinja2.exceptions.SecurityError.
Adapted from[0].
regards,
Hugo
[0] https://palletsprojects.com/blog/jinja-281-released/
--
Hugo Lefeuvre (hle)|www.owl.eu.com
RSA4096_ 360B 03B3 BF27 4F4D 7A3F D5E8 14AA 1EB8 A247 3DFD
ed25519_ 37B2 6D38 0B25 B8A2 6B9F 3A65 A36F 5357 5F2D DC4C
signature.asc
Description: PGP signature
March Report
Hi, Here is my LTS report for March. I was allocated 20 hours. I have spent all of them in the following tasks: sox: + Prepare, test and upload a security update addressing CVE-2017-15371, CVE-2017-11359, CVE-2017-11358 and CVE-2017-11332 (DLA 1705-1). liblivemedia: + Analyse liblivemedia patch for CVE-2019-9215 which, IMO, required some investigation before going on with the patch (severity was claimed to be critical but in the end we had very few info apart from the patch). This ended up being quite a lot of work. I produced a proof of concept, finally reported these issues on debbugs and prepared updates for both jessie and stretch (DLA 1720-1) (DSA-4408-1). Note that some work including the poc was not published yet, I plan to do it soon. sssd: + Analyse sssd CVE-2018-16838 and mark it no-dsa: GPO based access control not present in jessie. mysql-connector-python: + Investigate CVE-2019-2435 and mark it ignored in jessie. This CVE is potentially dangerous, but we have extremely few information about it from Oracle. Apart from marking it ignored we could 1. upgrade to 8.0.14 2. spend two weeks reverse-engineering the 8.0.14 release to extract information about the vulnerability and backport a highly hypothetical patch but I guess this is all out of the question here. hdf5: + triage work on undetermined issues. There is a huge backlog here, many undetermined issues, half-reported, duplicates, etc. I have started the triage report but this might take some more time. kde4libs: + Analyse CVE-2019-7443 to determine whether kauth fix applies to kde4libs, and whether we should release a dla or not. I concluded that it was in fact possible to apply the kauth patch to kde4libs but that the impact was way too low to take the risk to introduce regressions. I finally marked the issue no-dsa, more info in the commit message. misc: + various cve triage and update work of dla-needed. The report is coming a bit earlier this month, I ran out of hours quite quickly due to my liblivemedia, kde4libs and hdf5 work. I wanted to continue my work on faad2 but did not manage to find time for that, so I will try to finish this next month. Best Regards, Hugo -- Hugo Lefeuvre (hle)|www.owl.eu.com RSA4096_ 360B 03B3 BF27 4F4D 7A3F D5E8 14AA 1EB8 A247 3DFD ed25519_ 37B2 6D38 0B25 B8A2 6B9F 3A65 A36F 5357 5F2D DC4C signature.asc Description: PGP signature
Re: hdf5 undetermined cves
Hi Markus,
> I think it was unclear if upstream was even aware of those bugs. The
> CVEs were requested by someone who provides POCs but whether a certain
> version is affected or not is not clear and if patches are available. I
> would check with upstream first, forward links and POCS if necessary. In
> case they already know about the problem you could save a lot of time.
Thanks for your answer. I have received a few other answers off-list and
plan to proceed on a case by case basis, reporting bugs to upstream, trying
to get them fixed and spot duplicates.
cheers,
Hugo
--
Hugo Lefeuvre (hle)|www.owl.eu.com
RSA4096_ 360B 03B3 BF27 4F4D 7A3F D5E8 14AA 1EB8 A247 3DFD
ed25519_ 37B2 6D38 0B25 B8A2 6B9F 3A65 A36F 5357 5F2D DC4C
signature.asc
Description: PGP signature
hdf5 undetermined cves
Hi, I just noticed the large number of undetermined issues affecting the hdf5 source package in the tracker. I have tried to reproduce the latest one on buster, successfully (CVE-2019-9152, I have updated the tracker). I wonder why all these issues were marked undetermined in the first place. Did I miss something? regards, Hugo -- Hugo Lefeuvre (hle)|www.owl.eu.com RSA4096_ 360B 03B3 BF27 4F4D 7A3F D5E8 14AA 1EB8 A247 3DFD ed25519_ 37B2 6D38 0B25 B8A2 6B9F 3A65 A36F 5357 5F2D DC4C signature.asc Description: PGP signature
[SECURITY] CVE-2019-7443 (kauth) in kdelibs
Hi,
I'm Hugo Lefeuvre, from the Debian LTS team. I am currently working on
CVE-2019-7443 which appears to affect not only kauth but also kdelibs
since it ships a very similar kdecore/auth/backends/dbus/DBusHelperProxy.cpp
file[0].
As far as I am aware the fix for CVE-2019-7443 was not applied to
kdelibs. Is there a specific reason for that? Do you plan addressing this
potential vulnerability in kdelibs as well?
CC-ing publicly-archived debian-lts@lists.debian.org
regards,
Hugo Lefeuvre
[0] https://bugs.debian.org/922727
--
Hugo Lefeuvre (hle)|www.owl.eu.com
RSA4096_ 360B 03B3 BF27 4F4D 7A3F D5E8 14AA 1EB8 A247 3DFD
ed25519_ 37B2 6D38 0B25 B8A2 6B9F 3A65 A36F 5357 5F2D DC4C
signature.asc
Description: PGP signature
Re: recent DLAs not yet on www.debian.org
> Holger, I did read > > https://wiki.debian.org/LTS/Development#Publishing_updates_on_the_website > > but I have no permission to push to > > https://salsa.debian.org/webmaster-team/webwml > > Someone has to grant all of us write permissions. > > If you want to create merge requests, then it should be mentioned but I don't > really > think that this is an efficient way. I doubt this is the workflow of the > security team. I have asked for commit rights and got them right away :) https://salsa.debian.org/webmaster-team/webwml/merge_requests/62 -- Hugo Lefeuvre (hle)|www.owl.eu.com RSA4096_ 360B 03B3 BF27 4F4D 7A3F D5E8 14AA 1EB8 A247 3DFD ed25519_ 37B2 6D38 0B25 B8A2 6B9F 3A65 A36F 5357 5F2D DC4C signature.asc Description: PGP signature
Re: February Report
> Here is my LTS report for February.
>
> I was allocated 20 hours. I have spent all of them in the following
> tasks:
-> 19.5h, not 20.
--
Hugo Lefeuvre (hle)|www.owl.eu.com
RSA4096_ 360B 03B3 BF27 4F4D 7A3F D5E8 14AA 1EB8 A247 3DFD
ed25519_ 37B2 6D38 0B25 B8A2 6B9F 3A65 A36F 5357 5F2D DC4C
signature.asc
Description: PGP signature
February Report
Hi,
Here is my LTS report for February.
I was allocated 20 hours. I have spent all of them in the following
tasks:
* faad2:
+ work on patch for CVE-2018-20362. That was quite time consuming, the
issue is tightly bound to some very specific parts of the AAC standard
which is not exactly trivial. I have submitted a patch proposal and
currently wait for some feedback from upstream. See upstream bug
report.
* liblivemedia:
+ Prepare, test and upload a security update addressing CVE-2019-7314 and
CVE-2019-6256 (DLA-1690-1).
* qemu:
+ Investigation and triage of CVE-2018-16867, CVE-2019-3812 and CVE-2019-6501.
+ Take a last look at CVE-2018-19665 and mark it postponed since the final
patch might take some time to come out and the issue is not that critical
anyways.
+ Prepare, test and upload a security update addressing CVE-2019-6778,
CVE-2018-16872 and CVE-2018-12617 (DLA-1694-1).
* sssd:
+ Investigate CVE-2018-16838. I will publish the results soon.
* sox:
+ Prepare, test and upload a security update addressing CVE-2017-15370,
CVE-2017-15372, CVE-2017-18189 and CVE-2017-15642 (DLA 1695-1).
* cairo:
+ review current cves. All of them are small, not very practice relevant
crashes
with low security implications. Mark them no-dsa.
* kde4libs:
+ Start to work on CVE-2019-7443, but I didn't have much time remaining
for that. To be continued in march.
* tiff:
+ review Brian's work, c.f. mailing list.
Best Regards,
Hugo
--
Hugo Lefeuvre (hle)|www.owl.eu.com
RSA4096_ 360B 03B3 BF27 4F4D 7A3F D5E8 14AA 1EB8 A247 3DFD
ed25519_ 37B2 6D38 0B25 B8A2 6B9F 3A65 A36F 5357 5F2D DC4C
signature.asc
Description: PGP signature
qemu CVE-2019-6501: not-affected in Jessie and Stretch?
Hi,
It looks very much like the vulnerability was introduced in
a71c775b24ebc664129eb1d9b4c360590353efd5[0] which is not present prior
2.12.50.
I'd appreciate if a second pair of eyes could double check before I
update the tracker for Jessie and Stretch.
(scsi_handle_inquiry_reply was introduced in
0a96ca2437646bad197b0108c5f4a93e7ead05a9[1].
thanks!
cheers,
Hugo
[0]
https://git.qemu.org/?p=qemu.git;a=commit;h=a71c775b24ebc664129eb1d9b4c360590353efd5
[1]
https://git.qemu.org/?p=qemu.git;a=commit;h=0a96ca2437646bad197b0108c5f4a93e7ead05a9
--
Hugo Lefeuvre (hle)|www.owl.eu.com
RSA4096_ 360B 03B3 BF27 4F4D 7A3F D5E8 14AA 1EB8 A247 3DFD
ed25519_ 37B2 6D38 0B25 B8A2 6B9F 3A65 A36F 5357 5F2D DC4C
signature.asc
Description: PGP signature
Re: tiff
.. follow up of 20190212073152.ga2...@behemoth.owl.eu.com.local otherwise tests went fine. one more comment: > + * Non-maintainer upload by the LTS Team. > + * Fix CVE-2018-19210: NULL pointer dereference > +There is a NULL pointer dereference in the TIFFWriteDirectorySec function > +in tif_dirwrite.c that will lead to a denial of service attack, as > +demonstrated by tiffset. > + * Fix CVE-2018-17000: NULL pointer dereference > +A NULL pointer dereference in the function _TIFFmemcmp at tif_unix.c > (called > +from TIFFWriteDirectoryTagTransferfunction) allows an attacker > +to cause a denial-of-service through a crafted tiff file. This > vulnerability > +can be triggered by the executable tiffcp. This patch is actually the one for CVE-2019-7663, which happens to also fix CVE-2018-17000 (not confirmed by upstream yet?). I suggest to mention CVE-2019-7663 here. :) thanks! Hugo -- Hugo Lefeuvre (hle)|www.owl.eu.com RSA4096_ 360B 03B3 BF27 4F4D 7A3F D5E8 14AA 1EB8 A247 3DFD ed25519_ 37B2 6D38 0B25 B8A2 6B9F 3A65 A36F 5357 5F2D DC4C signature.asc Description: PGP signature
Re: tiff
Hi Brian,
I am currently testing the update. I already had a look at the patches.
> diff -Nru tiff-4.0.3/debian/patches/CVE-2018-12900.patch
> tiff-4.0.3/debian/patches/CVE-2018-12900.patch
> --- tiff-4.0.3/debian/patches/CVE-2018-12900.patch1970-01-01
> 10:00:00.0 +1000
> +++ tiff-4.0.3/debian/patches/CVE-2018-12900.patch2019-02-08
> 14:52:01.0 +1100
> @@ -0,0 +1,13 @@
> +--- a/tools/tiffcp.c
> b/tools/tiffcp.c
> +@@ -1394,6 +1394,10 @@
> + uint32 row;
> + uint16 bps, bytes_per_sample;
> +
> ++if (0x / tilew < spp) {
> ++TIFFError(TIFFFileName(in), "Error, either TileWidth (%u) or
> SamplePerPixel (%u) is too large", tilew, spp);
> ++return 0;
> ++}
> + tilebuf = _TIFFmalloc(tilesize);
> + if (tilebuf == 0)
> + return 0;
I don't really like this patch... it has not been merged yet (the PR has
been closed, so I guess it will never get merged) and looks more like a
hack to me.
What if tilew * spp = INT_MAX ?
Then oskew + iskew will still overflow. So this does not fix the issue.
cheers,
Hugo
--
Hugo Lefeuvre (hle)|www.owl.eu.com
RSA4096_ 360B 03B3 BF27 4F4D 7A3F D5E8 14AA 1EB8 A247 3DFD
ed25519_ 37B2 6D38 0B25 B8A2 6B9F 3A65 A36F 5357 5F2D DC4C
signature.asc
Description: PGP signature
Re: tiff
Hi,
> Attached is my proposed patch for tiff in Jessie.
I will be able to test the upload with my usual set of test files tomorrow
if necessary.
> +From d0a842c5dbad2609aed43c701a12ed12461d3405 Mon Sep 17 00:00:00 2001
> +From: Hugo Lefeuvre
> +Date: Wed, 21 Nov 2018 18:50:34 +0100
> +Subject: [PATCH] tif_dir: unset transferfunction field if necessary
Thanks for getting this patch merged :)
regards,
Hugo
--
Hugo Lefeuvre (hle)|www.owl.eu.com
RSA4096_ 360B 03B3 BF27 4F4D 7A3F D5E8 14AA 1EB8 A247 3DFD
ed25519_ 37B2 6D38 0B25 B8A2 6B9F 3A65 A36F 5357 5F2D DC4C
signature.asc
Description: PGP signature
January Report
Hi,
Here is my LTS report for January.
I was allocated 20 hours. I have spent all of them in the following
tasks:
* libsndfile:
+ Analyse upstream patch for CVE-2018-19758. Prepare, test and upload
security update addressing this issue (DLA-1632-1)
* qemu:
+ Investigate CVE-2018-19665, produce a trimmed down version of upstream
patch[0]. Not uploaded yet, I am still discussing what I consider to be
issues in the patch, and Philippe Mathieu-Daudé from RedHat is planning
to release an updated version soon[1].
+ Prepare, test and upload a security update addressing CVE-2018-17958,
CVE-2018-19489 and CVE-2018-19364 (DLA-1646-1)
* aria2:
+ Analyse, reproduce CVE-2019-3500, backport patch, test and upload it
(DLA-1636-1)
* libpng:
+ Analyse CVE-2019-6129 and mark it ignored, see my post on upstream's
bug report.
* openjpeg2:
+ Analyse CVE-2018-5727 and mark it in jessie. After discussion
with the security team decide to mark it unimportant in all suites.
* tmpreaper:
+ Analyse CVE-2019-3461, backport stretch update to jessie (DLA-1640-1)
* phpmyadmin:
+ review lucas' update, issues in table creation.
* faad2:
+ start working on patches. Nothing online yet, this is likely to take a
few weeks since there are many issues and patches have to be written
from scratch.
Best Regards,
Hugo
[0] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=916278
[1] https://lists.debian.org/debian-lts/2019/01/msg00071.html
--
Hugo Lefeuvre (hle)|www.owl.eu.com
RSA4096_ 360B 03B3 BF27 4F4D 7A3F D5E8 14AA 1EB8 A247 3DFD
ed25519_ 37B2 6D38 0B25 B8A2 6B9F 3A65 A36F 5357 5F2D DC4C
signature.asc
Description: PGP signature
Re: Review and testing phpmyadmin for Jessie LTS
Hi Lucas, > Great, sorry for being a victim of my lack of attention... I've never > used phpmyadmin (that's why I requested some testing) and my local tests > were so basic that they didn't catch this issue. Shame on me. That's fine, main thing is issues have been found before upload :) > I'll fix it and perform some tests. Thanks for the review and the time > that you spent on this. I am available for testing the updated package if needed. cheers, Hugo -- Hugo Lefeuvre (hle)|www.owl.eu.com RSA4096_ 360B 03B3 BF27 4F4D 7A3F D5E8 14AA 1EB8 A247 3DFD ed25519_ 37B2 6D38 0B25 B8A2 6B9F 3A65 A36F 5357 5F2D DC4C signature.asc Description: PGP signature
Re: [Qemu-devel] [PATCH v2] bt: use size_t type for length parameters instead of int
Hi Philippe, > I have been assigned to fix this issue, but rather fixing locally this > BT device, fix the pattern on all devices. > I'll post the series during the week and Cc you (and eventually the > Debian LTS list when it gets merged). The series obsoletes this patch, > so the plan is to not apply it. Thanks ! I will wait for your patch then. > > Any reason why assert() calls are used here ? > > > > These checks should always be executed, but they won't if user compiles > > without asserts. Also, AFAIK any assert failure will stop the qemu host > > process which is not what we want in this case. > > There was a discussion about this, and the outcome is QEMU does not > support building without assertions. See this commit: > > https://git.qemu.org/?p=qemu.git;a=blobdiff;f=include/qemu/osdep.h;h=9966638;hp=6855b94;hb=262a69f42;hpb=825bfa005 Makes sense. But I'm still sceptical about assert() being used here. For example: @@ -113,6 +113,7 @@ static void vhci_host_send(void *opaque, static uint8_t buf[4096]; buf[0] = type; +assert(len < sizeof(buf)); memcpy(buf + 1, data, len); while (write(s->fd, buf, len + 1) < 0) From my understanding assert() calls are supposed to be a way to verify code assumptions at runtime. assert failures are always bugs, so they terminate the process. If len is passed by guest systems, an excessive value should not be considered a bug but invalid user passed input, that is normal behaviour, right? In this case I expect qemu to simply reject the input instead of triggering an assert failure and terminating. regards, Hugo -- Hugo Lefeuvre (hle)|www.owl.eu.com RSA4096_ 360B 03B3 BF27 4F4D 7A3F D5E8 14AA 1EB8 A247 3DFD ed25519_ 37B2 6D38 0B25 B8A2 6B9F 3A65 A36F 5357 5F2D DC4C signature.asc Description: PGP signature
Re: [Qemu-devel] [PATCH v2] bt: use size_t type for length parameters instead of int
Hi, > The length parameter values are not negative, thus use an unsigned > type 'size_t' for them. Many routines pass 'len' values to memcpy(3) > calls. If it was negative, it could lead to memory corruption issues. > Add check to avoid it. I'm working on a Debian LTS security update for qemu and am currently thinking about addressing this issue as well. I see this patch has not been applied yet and the bluetooth subsystem is pending deprecation. Are you still considering to apply it? > @@ -113,6 +113,7 @@ static void vhci_host_send(void *opaque, > static uint8_t buf[4096]; > > buf[0] = type; > +assert(len < sizeof(buf)); > memcpy(buf + 1, data, len); > > while (write(s->fd, buf, len + 1) < 0) Any reason why assert() calls are used here ? These checks should always be executed, but they won't if user compiles without asserts. Also, AFAIK any assert failure will stop the qemu host process which is not what we want in this case. regards, Hugo -- Hugo Lefeuvre (hle)|www.owl.eu.com RSA4096_ 360B 03B3 BF27 4F4D 7A3F D5E8 14AA 1EB8 A247 3DFD ed25519_ 37B2 6D38 0B25 B8A2 6B9F 3A65 A36F 5357 5F2D DC4C signature.asc Description: PGP signature
Re: qemu - CVE-2018-19665: bt subsystem mishandles negative length variables
Hi Adrian, > On 1/12/19 5:52 PM, Hugo Lefeuvre wrote: > > the subsystem doesn't seem to be very actively maintained and that the user > > base is quite small, it is maybe better to mark this no-dsa in stretch and > > Please don't forget thet Debian has derivates that do not get summed up in > popcon.d.o. So the user base might be bigger than assumed. Right, but I was actually strictly speaking about the bluetooth subsystem, quoting qemu's upstream[0]. cheers Hugo [0] https://patchwork.kernel.org/patch/10678421/ -- Hugo Lefeuvre (hle)|www.owl.eu.com RSA4096_ 360B 03B3 BF27 4F4D 7A3F D5E8 14AA 1EB8 A247 3DFD ed25519_ 37B2 6D38 0B25 B8A2 6B9F 3A65 A36F 5357 5F2D DC4C signature.asc Description: PGP signature
Re: Review and testing phpmyadmin for Jessie LTS
Hi Lucas,
Sorry for the late answer.
I had an issue with your patch and took a while to find out what was going
wrong.
This update broke table creation...
> +--- a/libraries/transformations.lib.php
> b/libraries/transformations.lib.php
> +@@ -145,9 +145,10 @@ function PMA_getTransformationDescriptio
> + $class_name = explode(".class.php", $file);
> + $class_name = $class_name[0];
> +
> +-// include and instantiate the class
> +-include_once 'libraries/plugins/transformations/' . $file;
> +-return $class_name::getInfo();
> ++if (class_exists($class_name)) {
> ++return $class_name::getInfo();
> ++}
> ++return ''
I guess a ; is missing here :)
cheers,
Hugo
--
Hugo Lefeuvre (hle)|www.owl.eu.com
RSA4096_ 360B 03B3 BF27 4F4D 7A3F D5E8 14AA 1EB8 A247 3DFD
ed25519_ 37B2 6D38 0B25 B8A2 6B9F 3A65 A36F 5357 5F2D DC4C
signature.asc
Description: PGP signature
Re: qemu - CVE-2018-19665: bt subsystem mishandles negative length variables
> Anyways, given that the patch is quite large (though straightforward), that
> the subsystem doesn't seem to be very actively maintained and that the user
> base is quite small, it is maybe better to mark this no-dsa in stretch and
> jessie.
... but if we manage to trim down upstream's patch to just a few lines,
it could still be worth it.
I have taken upstream's patch and got rid of all type related changes
which don't have any security related impact. In fact they don't solve
the 'negative len' issue, these changes are just equivalent to moving the
size_t cast a few instructions earlier.
These changes might make sense in a refactoring perspective but this is
just noise in our case.
The resulting patch is tiny:
diff --git a/bt-host.c b/bt-host.c
index 2f8f631c25..b73a44d07d 100644
--- a/bt-host.c
+++ b/bt-host.c
@@ -113,6 +113,7 @@ static void vhci_host_send(void *opaque,
static uint8_t buf[4096];
buf[0] = type;
+assert((size_t) len < sizeof(buf));
memcpy(buf + 1, data, len);
while (write(s->fd, buf, len + 1) < 0)
diff --git a/hw/bt/hci-csr.c b/hw/bt/hci-csr.c
index 0341ded50c..26bd516d31 100644
--- a/hw/bt/hci-csr.c
+++ b/hw/bt/hci-csr.c
@@ -320,18 +320,18 @@ static int csrhci_write(struct Chardev *chr,
struct csrhci_s *s = (struct csrhci_s *)chr;
int total = 0;
-if (!s->enable)
+if (!s->enable || len <= 0)
return 0;
for (;;) {
int cnt = MIN(len, s->in_needed - s->in_len);
-if (cnt) {
-memcpy(s->inpkt + s->in_len, buf, cnt);
-s->in_len += cnt;
-buf += cnt;
-len -= cnt;
-total += cnt;
-}
+assert(cnt > 0);
+
+memcpy(s->inpkt + s->in_len, buf, cnt);
+s->in_len += cnt;
+buf += cnt;
+len -= cnt;
+total += cnt;
if (s->in_len < s->in_needed) {
break;
3 lines changed, omitting indentation related diff. Given that this
issue might allow host side DoS/memory corruption I don't think this is
exaggerated.
The only think which is still unclear to me is why the patch is checking
using assert(). If these assert() calls are standard ansi ones, then their
failure would stop the whole qemu process which is not exactly what we
want right?
cheers,
Hugo
--
Hugo Lefeuvre (hle)|www.owl.eu.com
RSA4096_ 360B 03B3 BF27 4F4D 7A3F D5E8 14AA 1EB8 A247 3DFD
ed25519_ 37B2 6D38 0B25 B8A2 6B9F 3A65 A36F 5357 5F2D DC4C
signature.asc
Description: PGP signature
Re: tmpreaper jessie update
Hi Moritz, > The new libmount dependency is necessary for the new check used by the > security > fix. Most of the additional autoconf noise is related to that new dependency > and to the fact that the last upload to unstable before the 1.6.14 one was in > 2010. > > If the debdiff for jessie is identical to the one in stretch (the base > versions > are identical after all), do a few functionality tests and you should be good. > If you strip the autoconf bits, the debdiff is also pretty small. Right, the debdiff is identical to the one in stretch putting apart changelog entries. I will do a few more tests and upload. Thanks ! cheers, Hugo -- Hugo Lefeuvre (hle)|www.owl.eu.com RSA4096_ 360B 03B3 BF27 4F4D 7A3F D5E8 14AA 1EB8 A247 3DFD ed25519_ 37B2 6D38 0B25 B8A2 6B9F 3A65 A36F 5357 5F2D DC4C signature.asc Description: PGP signature
tmpreaper jessie update
Dear security team,
I'm currently preparing a jessie security update addressing CVE-2019-3461,
based on 1.6.13+nmu1+deb9u1 (stretch version).
I see that the diff is quite huge (same code as buster 1.6.14 right?) and
adds a new libmount-dev dependency. I've had a look at the diff, tested it
in jessie and so far I'm fine with that (especially because it was already
uploaded to stretch).
However I want to make sure it fits well to jessie and will not be able to
review such a huge debdiff in detail myself, so I would like to ask you
whether you think there is anything I should be aware of about these
changes.
thanks !
cheers,
Hugo
--
Hugo Lefeuvre (hle)|www.owl.eu.com
RSA4096_ 360B 03B3 BF27 4F4D 7A3F D5E8 14AA 1EB8 A247 3DFD
ed25519_ 37B2 6D38 0B25 B8A2 6B9F 3A65 A36F 5357 5F2D DC4C
signature.asc
Description: PGP signature
Re: Review and testing phpmyadmin for Jessie LTS
Hi Lucas, > I uploaded version 4.2.12-2+deb8u4 of phpmyadmin to: > > https://people.debian.org/~kanashiro/jessie_lts/phpmyadmin/ > > It has patches fixing CVE-2018-19968 and CVE-2018-19970. I did not have > the time to determine whether jessie is affected by CVE-2018-19969 > (requested by sunweaver), I did some superficial investigation with no > confirmation yet. This month I'll not have enough time to continue the > investigation. > > I'd appreciate some review and testing, specially related to > CVE-2018-19968, the debdiff is attached if it helps. will have a look later today, thanks ! cheers, Hugo -- Hugo Lefeuvre (hle)|www.owl.eu.com RSA4096_ 360B 03B3 BF27 4F4D 7A3F D5E8 14AA 1EB8 A247 3DFD ed25519_ 37B2 6D38 0B25 B8A2 6B9F 3A65 A36F 5357 5F2D DC4C signature.asc Description: PGP signature
qemu - CVE-2018-19665: bt subsystem mishandles negative length variables
Hi,
I had a look at CVE-2018-19665 regarding qemu in oldstable/stable.
summary: the bluetooth subsystem uses signed length variables at multiple
places. These length variables are used, among others, in memcpy calls. A
malicious guest VM could attempt to crash the host by passing negative len
values (in fact, huge len values interpreted as negative numbers) to these
functions.
The suggested patch[0] changes the type of these length variables to size_t
(unsigned) and adds a few assert calls to make sure the code is also
resilient again large values of len.
First, it is not completely clear to me to what extent this length variable
is under the control of guest VM users.
say, if guest kernel drivers process calls first, then these large/negative
values are likely to be rejected before they have even reached the affected
qemu code. Under this hypothesis, guest VM users would need to have full
control over the guest kernel to exploit this vulnerability (making exploit
more difficult in real envs ?).
I might be wrong on this point due to my limited knowledge of this
code-base.
Anyways, given that the patch is quite large (though straightforward), that
the subsystem doesn't seem to be very actively maintained and that the user
base is quite small, it is maybe better to mark this no-dsa in stretch and
jessie.
Cheers,
Hugo
[0] https://lists.gnu.org/archive/html/qemu-devel/2018-11/msg03570.html
--
Hugo Lefeuvre (hle)|www.owl.eu.com
RSA4096_ 360B 03B3 BF27 4F4D 7A3F D5E8 14AA 1EB8 A247 3DFD
ed25519_ 37B2 6D38 0B25 B8A2 6B9F 3A65 A36F 5357 5F2D DC4C
signature.asc
Description: PGP signature
