Re: Updating chrony in wheezy-lts

[Markus Koschany]

On 12.12.2016 20:41, Vincent Blut wrote:
> Hello,
> 
> I would like to see chrony being updated in wheezy-lts to fix
> CVE-2016-1567. Also, I included a fix to make sure we don’t delete the
> /var/lib/chrony content. [...]

Hi,

the patch looks good to me. Please go ahead.

Regards,

Markus



signature.asc
Description: OpenPGP digital signature

Re: Updating chrony in wheezy-lts

[Vincent Blut]

On Tue, Dec 13, 2016 at 09:17:54AM +0100, Markus Koschany wrote:

On 12.12.2016 20:41, Vincent Blut wrote:

Hello,

I would like to see chrony being updated in wheezy-lts to fix
CVE-2016-1567. Also, I included a fix to make sure we don’t delete the
/var/lib/chrony content. [...]


Hi,

the patch looks good to me. Please go ahead.


Thanks, I need a sponsor though. Would you be willing to take the role?


Regards,

Markus


Cheers,
Vincent





signature.asc
Description: PGP signature

Re: Updating chrony in wheezy-lts

[Markus Koschany]

On 13.12.2016 16:30, Vincent Blut wrote:
> On Tue, Dec 13, 2016 at 09:17:54AM +0100, Markus Koschany wrote:
>> On 12.12.2016 20:41, Vincent Blut wrote:
>>> Hello,
>>>
>>> I would like to see chrony being updated in wheezy-lts to fix
>>> CVE-2016-1567. Also, I included a fix to make sure we don’t delete the
>>> /var/lib/chrony content. [...]
>>
>> Hi,
>>
>> the patch looks good to me. Please go ahead.
> 
> Thanks, I need a sponsor though. Would you be willing to take the role?

Sure. I'll take care of this.







signature.asc
Description: OpenPGP digital signature

Re: LTS frontdesk duties for 19th Dec → 1st Jan

[Chris Lamb]

Ola Lundqvist wrote:

> I can take both weeks. I have hours left this month.

Many thanks.

(Has been taken in lts-frontdesk.2016.txt)


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-

Additional 9pfs issue in qemu

[Hugo Lefeuvre]

Hi,

While having a look at CVE-2016-9913, I noticed that the virtio_9p_init
function in hw/9pfs/virtio-9p-device.c (renamed virtio_9p_device_realize
here[0]) doesn't clean allocated memory when encountering errors (in
the wheezy version it just does exit(1), issue fixed since this
commit[1], jessie is not affected).

I'd like to fix this issue. Should I create a tracker entry ?

Cheers,
 Hugo

[0] 
http://git.qemu.org/?p=qemu.git;a=commit;h=59be75227d3985c9f0a9f5396fc64e357a54defb
[1] 
http://git.qemu.org/?p=qemu.git;a=commit;h=92304bf3998cedcf3b1026a795edba7e1fd17c74

-- 
 Hugo Lefeuvre (hle)|www.owl.eu.com
4096/ ACB7 B67F 197F 9B32 1533 431C AC90 AC3E C524 065E


signature.asc
Description: PGP signature

Re: Updating chrony in wheezy-lts

[Vincent Blut]

On Tue, Dec 13, 2016 at 04:50:11PM +0100, Markus Koschany wrote:

On 13.12.2016 16:30, Vincent Blut wrote:

On Tue, Dec 13, 2016 at 09:17:54AM +0100, Markus Koschany wrote:

On 12.12.2016 20:41, Vincent Blut wrote:

Hello,

I would like to see chrony being updated in wheezy-lts to fix
CVE-2016-1567. Also, I included a fix to make sure we don’t delete the
/var/lib/chrony content. [...]


Hi,

the patch looks good to me. Please go ahead.


Thanks, I need a sponsor though. Would you be willing to take the role?


Sure. I'll take care of this.


Just saw it being accepted in oldstable. Thank you Markus!

Cheers,
Vincent


signature.asc
Description: PGP signature

Re: Additional 9pfs issue in qemu

[Ola Lundqvist]

Hi

Sorry for my lack of understanding. But why do them memory have to be
explicitly deallocated if exit is called? In what way is that a security
issue?

I´m asking as I have seen problems with deallocation more than once.
Especially in error handlers.

/ Ola

Sent from a phone

Den 13 dec 2016 18:11 skrev "Hugo Lefeuvre" :

Hi,

While having a look at CVE-2016-9913, I noticed that the virtio_9p_init
function in hw/9pfs/virtio-9p-device.c (renamed virtio_9p_device_realize
here[0]) doesn't clean allocated memory when encountering errors (in
the wheezy version it just does exit(1), issue fixed since this
commit[1], jessie is not affected).

I'd like to fix this issue. Should I create a tracker entry ?

Cheers,
 Hugo

[0] http://git.qemu.org/?p=qemu.git;a=commit;h=
59be75227d3985c9f0a9f5396fc64e357a54defb
[1] http://git.qemu.org/?p=qemu.git;a=commit;h=
92304bf3998cedcf3b1026a795edba7e1fd17c74

--
 Hugo Lefeuvre (hle)|www.owl.eu.com
4096/ ACB7 B67F 197F 9B32 1533 431C AC90 AC3E C524 065E

Fwd: Re: BUG: graphicsmagick CVE-2016-5240 wrong in Debian-Wheezy

[Chris Lamb]

[Forwarding after getting ACK]

- Original message -
From: Chris Lamb 
To: Philipp Hahn , secur...@debian.org, "Laszlo Boszormenyi 
(GCS)" 
Cc: Bob Friesenhahn 
Subject: Re: BUG: graphicsmagick CVE-2016-5240 wrong in Debian-Wheezy
Date: Tue, 13 Dec 2016 17:34:20 +0100

Philipp Hahn wrote:

> Hello Chris,
> 
> @Bob: it's a Debian only bug, just FYI
> 
> the issue  is
> not fixed correctly in Debian-Wheezy; it is broken since first
> 1.3.16-1.1+deb7u3 and still in latest 1.3.16-1.1+deb7u5: "gm" crashes
> with a SEGV using the original test data from
> :

Oh dear. I've marked this as such in the trackers and it should be worked
on ASAP. Note that the DLA announcement mail also included a typo:

 https://lists.debian.org/debian-lts-announce/2016/07/msg8.html

ie. DLA-574-1 should be DLA-547-1.

Philip? Can I forward this mail to the debian-lts mailing list? (Quoting
in full below so I sent it verbatim if you ACK…)



> wget -O circular.svg http://seclists.org/oss-sec/2016/q2/att-180
> /circular_svg.bin
> gdb --args gm convert circular.svg bmp:/dev/null
> >  Program received signal SIGSEGV, Segmentation fault.
> >  0x779c88d8 in DrawImage (image=image@entry=0x5576d490, 
> > draw_info=draw_info@entry=0x55769320)
> >  at magick/render.c:2518
> >   2518  graphic_context[n]->dash_pattern[j-x];
> >  (gdb) print graphic_context[n]->dash_pattern
> >  $4 = (double *) 0x0
> >  (gdb) bt
> >  #0  0x779c88d8 in DrawImage (image=image@entry=0x5576d490, 
> > draw_info=draw_info@entry=0x55769320)
> >  at magick/render.c:2518
> >  #1  0x77a662c4 in ReadMVGImage (image_info=0x55766f00, 
> > exception=0x7fffde00) at coders/mvg.c:186
> >  #2  0x7795f7e8 in ReadImage 
> > (image_info=image_info@entry=0x5576a900, 
> >  exception=exception@entry=0x7fffde00) at magick/constitute.c:1596
> >  #3  0x77a97826 in ReadSVGImage (image_info=0x55764db0, 
> > exception=0x7fffde00) at coders/svg.c:2752
> >  #4  0x7795f7e8 in ReadImage 
> > (image_info=image_info@entry=0x55760be0, 
> >  exception=exception@entry=0x7fffde00) at magick/constitute.c:1596
> >  #5  0x7794b754 in ConvertImageCommand (image_info=0x55760be0, 
> > argc=3, argv=0x55762d30, 
> >  metadata=0x0, exception=0x7fffde00) at magick/command.c:3998
> >  #6  0x779329b3 in MagickCommand 
> > (image_info=image_info@entry=0x55760be0, argc=argc@entry=3, 
> >  argv=argv@entry=0x7fffe750, 
> > metadata=metadata@entry=0x7fffddf8, 
> >  exception=exception@entry=0x7fffde00) at magick/command.c:8314
> >  #7  0x77957e0d in GMCommand (argc=3, argv=0x7fffe750) at 
> > magick/command.c:16252
> >  #8  0x74799ead in __libc_start_main () from 
> > /lib/x86_64-linux-gnu/libc.so.6
> >  #9  0x48e1 in _start ()
> 
> The version in Jessie is not affected.
> 
> magick/render.c:
> > 2493graphic_context[n]->dash_pattern=
> > 2494  MagickAllocateArray(double 
> > *,(2*x+1),sizeof(double));
> here the memory is allocated
> > 2495if (graphic_context[n]->dash_pattern == (double *) 
> > NULL)
> > 2496  {
> > 2497
> > ThrowException3(&image->exception,ResourceLimitError,
> > 2498  MemoryAllocationFailed,UnableToDrawOnImage);
> > 2499break;
> > 2500  }
> > 2501for (j=0; j < x; j++)
> > 2502{
> > 2503  MagickGetToken(q,&q,token,token_max_length);
> > 2504  if (*token == ',')
> > 2505MagickGetToken(q,&q,token,token_max_length);
> > 2506  
> > graphic_context[n]->dash_pattern[j]=MagickAtoF(token);
> > 2507  if (graphic_context[n]->dash_pattern[j] < 0.0)
> > 2508status=MagickFail;
> > 2509  if (status == MagickFail)
> > 2510{
> > 2511  
> > MagickFreeMemory(graphic_context[n]->dash_pattern);
> here it is freed
> > 2512  break;
> this only breaks the loop from line 2501, but not the switch/case statement.
> > 2513}
> > 2514}
> WRONG! This is too late and needs to go up 6 lines.
> > 2515if (x & 0x01)
> > 2516  for ( ; j < (2*x); j++)
> > 2517graphic_context[n]->dash_pattern[j]=
> > 2518  graphic_context[n]->dash_pattern[j-x];
> here it crashes
> 
> 
> The Debian patch
> graphicsmagick-1.3.16/debian/patches/CVE-2016-5240.patch is buggy:
> >  31 @@ -2505,6 +2504,13 @@
> >  32if (*token == ',')
> >  33  

Re: Additional 9pfs issue in qemu

[Hugo Lefeuvre]

Hi Ola,

> Sorry for my lack of understanding. But why do them memory have to be
> explicitly deallocated if exit is called? In what way is that a security
> issue?
> 
> I´m asking as I have seen problems with deallocation more than once.
> Especially in error handlers.

Thank you for the advice. You're right: if exit is called, memory leakage
is not really a problem since the operating system should handle the
deallocation.

However, it looks like it is not the case of proxy_init in virtio-9p-proxy.c,
since the function just returns -1.

But I'm not sure it's worth taking time for it...

Cheers,
 Hugo

-- 
 Hugo Lefeuvre (hle)|www.owl.eu.com
4096/ ACB7 B67F 197F 9B32 1533 431C AC90 AC3E C524 065E


signature.asc
Description: PGP signature

Re: phpmyadmin / CVE-2016-9861 / PMASA-2016-66

[Brian May]

>From what I can tell, phpmyadmin may in wheezy may not be vulnerable to
CVE-2016-9861 / PMASA-2016-66 because I can't find the vulnerable code.
-- 
Brian May 

Re: phpmyadmin / CVE-2016-9861 / PMASA-2016-66

[Brian May]

Brian May  writes:

> From what I can tell, phpmyadmin may in wheezy may not be vulnerable to
> CVE-2016-9861 / PMASA-2016-66 because I can't find the vulnerable code.

Hmmm... Looks like the PMA_isAllowedDomain() function was created in
response to CVE-2016-4412 / PMASA-2016-57 which hasn't been fixed yet in
wheezy.

The included patch at
https://github.com/phpmyadmin/phpmyadmin/commit/6f413680b172ae0b25f2509f1c7bb21405e8eaf9
doesn't appear to include the vulnerability however.
-- 
Brian May 

Re: Additional 9pfs issue in qemu

[Ola Lundqvist]

Hi Hugo

I guess it depends on how large the memory leak is and how often it would occur.
A small memory leak is not a security problem. But if it occurs often
and/or it is a very large thing seldom then it could cause DoS and
then it is a security problem.

I do not have the details to judge that.

Best regards

// Ola

On 13 December 2016 at 23:47, Hugo Lefeuvre  wrote:
> Hi Ola,
>
>> Sorry for my lack of understanding. But why do them memory have to be
>> explicitly deallocated if exit is called? In what way is that a security
>> issue?
>>
>> I´m asking as I have seen problems with deallocation more than once.
>> Especially in error handlers.
>
> Thank you for the advice. You're right: if exit is called, memory leakage
> is not really a problem since the operating system should handle the
> deallocation.
>
> However, it looks like it is not the case of proxy_init in virtio-9p-proxy.c,
> since the function just returns -1.
>
> But I'm not sure it's worth taking time for it...
>
> Cheers,
>  Hugo
>
> --
>  Hugo Lefeuvre (hle)|www.owl.eu.com
> 4096/ ACB7 B67F 197F 9B32 1533 431C AC90 AC3E C524 065E