Bug#1050836: oggvideotools: Looking at CVE-2020-21724

[Petter Reinholdtsen <pere@hungry.com>]

[Moritz Mühlenhoff]
> CVE-2020-21724[2]:
> | Buffer Overflow vulnerability in ExtractorInformation function in
> | streamExtractor.cpp in oggvideotools 0.9.1 allows remaote attackers
> | to run arbitrary code via opening of crafted ogg file.
> 
> https://sourceforge.net/p/oggvideotools/bugs/9

I had a look at this, but ran out of time.  This patch indicate the
crash point in getStreamConfig().  Unfortunately there is no way to
return an error from getStreamConfig(), so I believe the error should
be detected in StreamSerializer::open(), possibly in extractStreams(),
but I was unable to figure out how to properly do this in the time I
had available to look at the issue.

Index: oggvideotools-salsa/src/main/streamSerializer.cpp
===================================================================
--- oggvideotools-salsa.orig/src/main/streamSerializer.cpp      2024-09-08 07:50:48.030275614 +0200
+++ oggvideotools-salsa/src/main/streamSerializer.cpp   2024-09-08 08:29:04.726304778 +0200
@@ -19,6 +19,7 @@
  *
  */
 
+#include <assert.h>
 #include <iostream>
 
 #include "streamSerializer.h"
@@ -215,6 +220,10 @@
 
   for (; it != streamList.end(); ++it) {
     StreamEntry& entry = it->second;
+    printf("No %d size %d\n",
+          entry.streamConfig.streamNo,
+          streamList.size());
+    assert(entry.streamConfig.streamNo < streamList.size());
     packetList[entry.streamConfig.streamNo] = entry.streamConfig;
   }
 

Note, the output for the problematic oggLength_SEGV_heap-overflow file
fetched from the upstream issue is "No 1 size 1".  As far as I
understand it, the stream number should have been 0.

-- 
Happy hacking
Petter Reinholdtsen