From $URL: Function real_get_rdt_chunk() calls rtsp_read_data() to read RDT (Real Data Transport) chunks headers from the network and after that it will parse them. A controled variable is used to allocate a buffer and later passed on to the rtsp_read_data() function in order to specify the length of an RDT chunk data to read from the network. An integer underflow can be triggered when parsing a malformed RDT header chunk, a remote attacker can exploit it to execute arbitrary code in the context of the application. VLC Source file: modules/access/rtsp/real.c function: int real_get_rdt_chunk_header(rtsp_client_t *rtsp_session, rmff_pheader_t *ph)
Fixed in VLC 1.0.1, already tagged in upstream git, but not yet released. Patch available at http://git.videolan.org/?p=vlc.git;a=commit;h=dc74600c97eb834c08674676e209afa842053aca
So it is indeed exploitable... We'll have two options: 0.9.10 or 1.0.1 I'd really prefer going for 1.0.1 stable as it fixes a couple of UI regressions from 0.9.x but it is a bit young so I'd like arch testers to take extra care there and refuse stable if there's too much annoying stuff (we may have a 0.9.10 very soon too). Anyway, we'll see what will be released and when.
1.0.1 is now on the download site: http://download.videolan.org/pub/videolan/vlc/1.0.1/ Alexis, your call.
0.9.10 and 1.0.1 are both in cvs now.
Arches, please test and mark stable: =media-video/vlc-0.9.10 =media-video/vlc-1.0.1 (see comment #2) Target keywords : "alpha amd64 ppc sparc x86"
amd64/x86 stable
(In reply to comment #6) > amd64/x86 stable It seems you've only been with 0.9.10 and I'd like to know why... the request was more: go for 1.0.1 unless absolutely needed and the part that seemed obvious to me: report why. Upstream has no plan to support 0.9.x anymore... http://mailman.videolan.org/pipermail/vlc-devel/2009-July/063528.html
(In reply to comment #7) > (In reply to comment #6) > > amd64/x86 stable > > It seems you've only been with 0.9.10 and I'd like to know why... the request > was more: go for 1.0.1 unless absolutely needed and the part that seemed > obvious to me: report why. Upstream has no plan to support 0.9.x anymore... basically b/c of the deps needing stable, but it looks like they do not have any open bugs. so should I go for these packages? =media-video/vlc-1.0.1 =media-libs/libdvbpsi-0.1.6 =net-libs/libproxy-0.2.3-r2 =media-libs/libtiger-0.3.3
(In reply to comment #8) > (In reply to comment #7) > > (In reply to comment #6) > > > amd64/x86 stable > > > > It seems you've only been with 0.9.10 and I'd like to know why... the request > > was more: go for 1.0.1 unless absolutely needed and the part that seemed > > obvious to me: report why. Upstream has no plan to support 0.9.x anymore... > > basically b/c of the deps needing stable, but it looks like they do not have > any open bugs. so should I go for these packages? > =media-video/vlc-1.0.1 > =media-libs/libdvbpsi-0.1.6 > =net-libs/libproxy-0.2.3-r2 > =media-libs/libtiger-0.3.3 yes please
amd64/x86: please have a look at the previous comments, we should go for media-video/vlc-1.0.1 and deps.
This also needs a newer libtool.
(In reply to comment #11) > This also needs a newer libtool. Hu? It's fine here and according to the deps it doesn't. If you dont explain in more details what the problem is, chances are great this won't get fixed soon... (assuming there is something to fix)
(In reply to comment #12) > (In reply to comment #11) > > This also needs a newer libtool. > > Hu? It's fine here and according to the deps it doesn't. If you dont explain in > more details what the problem is, chances are great this won't get fixed > soon... (assuming there is something to fix) USE=pulseaudio wants a newer pulseaudio (I chose 0.9.15-r2) and this pulls in a newer libtool.
(In reply to comment #13) > (In reply to comment #12) > > (In reply to comment #11) > > > This also needs a newer libtool. > > > > Hu? It's fine here and according to the deps it doesn't. If you dont explain in > > more details what the problem is, chances are great this won't get fixed > > soon... (assuming there is something to fix) > > USE=pulseaudio wants a newer pulseaudio (I chose 0.9.15-r2) and this pulls in > a newer libtool. Ok, thanks. Forget about 1.0.1 and go for 0.9.10 for now then. I didn't notice this was pulling ~arch pulseaudio too :/ We'll see about 1.0.x going stable in another bug later.
ppc stable
alpha/sparc stable
GLSA request filed.
There is no <media-video/vlc-1.0.6 in portage any more.
Can one of our new scouts check if there is a CVE for this and request one if there is none?
This appears to be CVE-2010-2062 - I don't have edit privileges to update the summary or alias.
Where did you find that, I don't see it here: http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2010-2062 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-2062
Sorry, I found that from Debian with the same git commit: http://security-tracker.debian.org/tracker/CVE-2010-2062 Description VLC: integer underflow in Real RTSP
Thanks for searching! :)
This issue was resolved and addressed in GLSA 201411-01 at http://security.gentoo.org/glsa/glsa-201411-01.xml by GLSA coordinator Sean Amoss (ackle).
