search for: cves

Hi Ralph, Thank you for your reply! For context -- we consider reported CVEs as bugs even if it's in a third-party library we use (such as libvorbis). We first determine if the CVE is something that would impact our customer workflows. In this case because of our use of libvorbis for audio I/O, it does impact our customers so we need to resolve the CVE as soon as poss...

...t httpd24-httpd-2.4.25-9.el7 to my organization, but I do not see it as being available on the mirror.centos.org site. I see a git commit for this package in April and was wondering how long it takes an rpm to become available once the commit has been completed. Also, I don't see the following CVEs addressed in any httpd24 changelogs and wanted to know if they were ever planning on being addressed in an httpd24 rpm? - CVE-2016-0736 - CVE-2016-2161 - CVE-2016-8743 - CVE-2016-1546 - CVE-2016-8740 -- Thanks, Tyler

...Cheers, Ralph On Mon, 2020-06-29 at 21:27 +0000, Ellen Johnson wrote: > Hi Ralph and libvorbis developers, > I thought the vorbis gitlab project was the main development site ( > https://gitlab.xiph.org/xiph/vorbis) because that's what the NVD CVE > tracker points to for the two CVEs I mentioned. But I just realized > there's also a vorbis github project (https://github.com/xiph/vorbis) > . Both appear to have recent activity. > Is the gitlab project the correct one to get the CVE fixes from so > we can patch our 1.3.6 to have latest security fixes? > T...

Erik de Castro Lopo wrote: > I think I have an alternative fix for the CVE which should not break > seeking. I'm working on getting an copy of the file with which to test. Patch applied and pushed. commit b4b2910bdca010808ccf2799f55562fa91f4347b Author: Erik de Castro Lopo <erikd at mega-nerd.com> Date: Wed Dec 10 18:54:16 2014 +1100

...a bit of code, so it'll take some time. I think the problem is that because bogus headers might pop up in the stream of which the CRC checks out, the whole frame is decoded to validate that a frame is correct. The bogus header might trigger the sanity checks that were made to fail by the CVEs, thereby the seek fails. A fix for this might be not decoding a frame fully, (by making the /*do_full_decode=*/true in FLAC__stream_decoder_process_single conditionally dependent on decoder->private_->is_seeking) but instead implement more sanity checks. For example, it could be checked...

Alexander, These are the only two CVEs from 2016 that I found contained in the RPM that you referenced. - add security fix for CVE-2016-5387 - mod_ssl: add security fix for CVE-2016-4979 -- Tyler Waldo Information Security Associate Threat and Vulnerability Management Mobile: (650) 410-0776 On Tue, Dec 19, 2017 at 10:39 AM, Alexand...

On Tue, Nov 25, 2014 at 12:29:33AM -0800, Erik de Castro Lopo wrote: > Google Security Team member, Michele Spagnuolo, recently found two potential > problems in the FLAC code base. They are : > > > CVE-2014-9028 : Heap buffer write overflow > https://git.xiph.org/?p=flac.git;a=commit;h=fcf0ba06ae12ccd7c67cee3c8d948df15f946b85 I'm trying to figure out how this one

Miroslav Lichvar wrote: > I'm trying to figure out how this one works. It seems the problem is > integer underflow in the "frame.header.blocksize-order" expression > used in read_subframe_fixed_() and read_subframe_lpc_() to get the > number of encoded samples, which causes a buffer overflow in the > LPC/fixed subframe decoding. > > The fix prevents that by

Brian Willoughby wrote: > While we're on the topic, what sort of consequences are there, really, > with this vulnerability? Worst case, your player stops playing on a > file that cannot be played anyway. Yes, it's bad that you have to > power-cycle the player to get it to restart, but it's not like you > can be doing anything else at the same time you're playing a

On 9.12.2014 20:33, Tristan Matthews wrote: > On Tue, Dec 9, 2014 at 1:31 PM, Janne Hyv?rinen <cse at sci.fi > <mailto:cse at sci.fi>> wrote: > > On 25.11.2014 12:14, Miroslav Lichvar wrote: > > I think the case with non-zero partition order may need to be fixed > > too. For example, with partition order of 1, predictor order of > 16 and >

On 9.12.2014 20:31, Janne Hyv?rinen wrote: > On 25.11.2014 12:14, Miroslav Lichvar wrote: >> I think the case with non-zero partition order may need to be fixed >> too. For example, with partition order of 1, predictor order of 16 and >> blocksize of 4, the function would return true and blocksize-order in >> the caller would still underflow. >> >> ---

Janne Hyv?rinen wrote: > In general I'm against patches that error out at the first sign of > corruption instead of gracefully handling the situation and continuing > from the next good bytes. I put the need for secure un-exploitable code at the top of my list for any code which operates on data from un-trusted sources. Sorry, that's not negotiable :-). > I think it would

Janne Hyv?rinen wrote: >> Can you share samples? > > It's a 470 MB copyrighted music album. I could but I don't think it's legal. How about sharing the album name (if it's popular enough)? (but then it would be good to post its CUETools verification log if the album has multiple pressings with different offsets...)

On Wed, Dec 10, 2014 at 10:54:15PM -0800, Erik de Castro Lopo wrote: > Erik de Castro Lopo wrote: > > > I think I have an alternative fix for the CVE which should not break > > seeking. I'm working on getting an copy of the file with which to test. > > Patch applied and pushed. I think this revives the CVE, at least in some configurations. The patch seems to cover

Op 11-12-14 om 10:53 schreef Martijn van Beurden: > Op 11-12-14 om 10:05 schreef Miroslav Lichvar: >> but I'd rather see the real seeking bug fixed instead > > I think I might have a fix [...] Another solution might be to 'just try again' somewhere else when seeking fails, but maybe there are good reasons not to do so? The decoder might get stuck in a loop?

2014-12-11 14:34 GMT+01:00 Miroslav Lichvar <mlichvar at redhat.com>: > > On Thu, Dec 11, 2014 at 11:12:25AM +0100, Martijn van Beurden wrote: > > Op 11-12-14 om 10:53 schreef Martijn van Beurden: > > > Op 11-12-14 om 10:05 schreef Miroslav Lichvar: > > >> but I'd rather see the real seeking bug fixed instead > > > > > > I think I might

On Thu, Dec 11, 2014 at 11:12:25AM +0100, Martijn van Beurden wrote: > Op 11-12-14 om 10:53 schreef Martijn van Beurden: > > Op 11-12-14 om 10:05 schreef Miroslav Lichvar: > >> but I'd rather see the real seeking bug fixed instead > > > > I think I might have a fix [...] So the problem is that FLAC__stream_decoder_process_single returns error before it finds a

...is-dev at xiph.org Subject: libvorbis release for recent CVE fixes? Hi libvorbis developers, I hope you all are well! Here at MathWorks we use libvorbis as part of our MATLAB audio I/O functionality, and our current version is your latest version 1.3.6. We've had the following libvorbis CVEs reported to us which appear to be fixed in your gitlab master branch and which impact our customer workflows: CVE-2018-10392 (looks like it's fixed via gitlab issue 2335) CVE-2018-10393 (looks like it's fixed via gitlab issue 2334, but the link to its duplicate issue 2330 does not...

Hi all, Google Security Team member, Michele Spagnuolo, recently found two potential problems in the FLAC code base. They are : CVE-2014-9028 : Heap buffer write overflow CVE-2014-8962 : Heap buffer read overflow For Linux distributions, the specific fixes for these two CVEs are available from Git here: https://git.xiph.org/?p=flac.git;a=commit;h=fcf0ba06ae12ccd7c67cee3c8d948df15f946b85 https://git.xiph.org/?p=flac.git;a=commit;h=5b3033a2b355068c11fe637e14ac742d273f076e and are simple enough that they should apply cleanly to the last official release 1.3.0 an...

Hi Ralph and libvorbis developers, I thought the vorbis gitlab project was the main development site (https://gitlab.xiph.org/xiph/vorbis) because that's what the NVD CVE tracker points to for the two CVEs I mentioned. But I just realized there's also a vorbis github project (https://github.com/xiph/vorbis). Both appear to have recent activity. Is the gitlab project the correct one to get the CVE fixes from so we can patch our 1.3.6 to have latest security fixes? Thanks! ellen -----Or...