Vorbis issueshttps://gitlab.xiph.org/xiph/vorbis/-/issues2020-06-11T04:25:08Zhttps://gitlab.xiph.org/xiph/vorbis/-/issues/2340divide by zero issue2020-06-11T04:25:08Zniugxdivide by zero issuethere is divide by zero issue when parameter word of ov_read_filter is 0 in vorbisfile.c file.
parameter word set by ov_read API, and user can set any value to word.
long ov_read_filter(OggVorbis_File *vf,char *buffer,int length,
.....there is divide by zero issue when parameter word of ov_read_filter is 0 in vorbisfile.c file.
parameter word set by ov_read API, and user can set any value to word.
long ov_read_filter(OggVorbis_File *vf,char *buffer,int length,
...
if(samples>0){
/* yay! proceed to pack data into the byte buffer */
long channels=ov_info(vf,-1)->channels;
long bytespersample=word * channels;
vorbis_fpu_control fpu;
// bytespersample is 0 when parameter word is 0, then divide by zero.
if(samples>length/bytespersample)samples=length/bytespersample;
POC:
modify parameter word of line 67 of vorbisfile_example.c to 0, like following:
long ret=ov_read(&vf,pcmout,sizeof(pcmout),0,0,1,¤t_section);
compile vorbisfile_example and run like this :
cat xxxx.ogg | .libs/vorbisfile_example
floating point exception occured.
If you indentify this issue as a vulnerability, please provide me with following information:
1.the affected versions.
2.patch
3.please assign a CVE-ID, discoverer is Guoxiang Niu, EaglEye Team
thank youhttps://gitlab.xiph.org/xiph/vorbis/-/issues/2339Remove C++ comments2019-01-28T23:00:38ZHenry BentRemove C++ commentsThere are the following c++ style comments which should not be in plain c files:
-lib/res0.c (lines 33 and 34)
-lib/sharedbook.c (lines 53 and 305)There are the following c++ style comments which should not be in plain c files:
-lib/res0.c (lines 33 and 34)
-lib/sharedbook.c (lines 53 and 305)https://gitlab.xiph.org/xiph/vorbis/-/issues/2335Four heap buffer overflow(read and write) vuls in function mapping0_forward()...2020-07-16T17:24:00ZJiangxinFour heap buffer overflow(read and write) vuls in function mapping0_forward() of libvorbis-1.3.6, which is caused by lacking of var “channels” check.I found four heap buffer overflow vuls in function mapping0_forward() of libvorbis-1.3.6 by fuzzing libtheora, one of the crash sample behaves as follows, others behave similar:
```
Program received signal SIGABRT, Aborted.
0x00007ffff6...I found four heap buffer overflow vuls in function mapping0_forward() of libvorbis-1.3.6 by fuzzing libtheora, one of the crash sample behaves as follows, others behave similar:
```
Program received signal SIGABRT, Aborted.
0x00007ffff6fdfb55 in raise () from /lib64/libc.so.6
(gdb) bt
#0 0x00007ffff6fdfb55 in raise () from /lib64/libc.so.6
#1 0x00007ffff6fe1131 in abort () from /lib64/libc.so.6
#2 0x0000000000520a0b in __sanitizer::Abort () at /home/jiangxin/hunter-tool/llvm5/projects/compiler-rt/lib/sanitizer_common/sanitizer_posix_libcdep.cc:146
#3 0x000000000051eb3a in __sanitizer::Die () at /home/jiangxin/hunter-tool/llvm5/projects/compiler-rt/lib/sanitizer_common/sanitizer_termination.cc:59
#4 0x00000000005051a5 in ~ScopedInErrorReport (this=<optimized out>, __in_chrg=<optimized out>) at /home/jiangxin/hunter-tool/llvm5/projects/compiler-rt/lib/asan/asan_report.cc:225
#5 __asan::ReportGenericError (pc=<optimized out>, bp=bp@entry=140737488324304, sp=sp@entry=140737488324296, addr=<optimized out>, is_write=is_write@entry=false, access_size=access_size@entry=4, exp=<optimized out>, exp@entry=0, fatal=<optimized out>, fatal@entry=true) at /home/jiangxin/hunter-tool/llvm5/projects/compiler-rt/lib/asan/asan_report.cc:420
#6 0x0000000000505c03 in __asan::__asan_report_load4 (addr=<optimized out>) at /home/jiangxin/hunter-tool/llvm5/projects/compiler-rt/lib/asan/asan_rtl.cc:133
#7 0x000000000069fac3 in mapping0_forward (vb=0x7fffffffd330) at mapping0.c:370
#8 0x00000000006244af in vorbis_analysis (vb=0x7fffffffd330, op=0x0) at analysis.c:46
#9 0x000000000052f14e in fetch_and_process_audio (audio=0x616000000380, audiopage=0x7fffffffd5e0, vo=0x7fffffffceb0, vd=0x7fffffffd260, vb=0x7fffffffd330, audioflag=0) at encoder_example.c:996
#10 0x0000000000536546 in main (argc=5, argv=0x7fffffffdfe8) at encoder_example.c:1754
(gdb)
```
These vuls are because of lacking of var “channels” check”, and here is the details of these four vuls in mapping0.c:
vul 1: line 370 of mapping0.c
```
366 for(i=0;i<vi->channels;i++){
367 /* the encoder setup assumes that all the modes used by any
368 specific bitrate tweaking use the same floor */
369
370 int submap=info->chmuxlist[i];//int array[256] oob read, vi->channels need check
```
vul 2: line 614 of mapping0.c
```
612 /* encode floor, compute masking curve, sep out residue */
613 for(i=0;i<vi->channels;i++){
614 int submap=info->chmuxlist[i];//int array[256] oob read, vi->channels need check
615 int *ilogmask=iwork[i];
```
vul 3 and 4: line 666 and 678 of mapping0.c
```
665 for(j=0;j<vi->channels;j++){
666 if(info->chmuxlist[j]==i){//int array[256] oob write, vi->channels need check
667 zerobundle[ch_in_bundle]=0;
668 if(nonzero[j])zerobundle[ch_in_bundle]=1;
669 couple_bundle[ch_in_bundle++]=iwork[j];
670 }
671 }
672
673 classifications=_residue_P[ci->residue_type[resnum]]->
674 class(vb,b->residue[resnum],couple_bundle,zerobundle,ch_in_bundle);
675
676 ch_in_bundle=0;
677 for(j=0;j<vi->channels;j++)
678 if(info->chmuxlist[j]==i)//int array[256] oob write, vi->channels need check
679 couple_bundle[ch_in_bundle++]=iwork[j];
680
681 _residue_P[ci->residue_type[resnum]]->
682 forward(opb,vb,b->residue[resnum],
683 couple_bundle,zerobundle,ch_in_bundle,classifications,i);
```
Note: I need compile libtheora and libvorbis by clang asan and use encoder_example of libtheora to reproduce this vul.
The cmdline to reproduce this vul is like this :
./encoder_example crash_sample xxx.y4m -o out.ogv
The binary encoder_example belongs to libtheora.
recommanded patch : adding on line 238 of mapping0.c
```
230 static int mapping0_forward(vorbis_block *vb){
231 vorbis_dsp_state *vd=vb->vd;
232 vorbis_info *vi=vd->vi;
233 codec_setup_info *ci=vi->codec_setup;
234 private_state *b=vb->vd->backend_state;
235 vorbis_block_internal *vbi=(vorbis_block_internal *)vb->internal;
236 int n=vb->pcmend;
237 int i,j,k;
238 if(vi->channels > MAX_CHANNEL || vi->channels < 0) return -1;//recommanded patch for these vuls
```https://gitlab.xiph.org/xiph/vorbis/-/issues/2334Stack buffer overflow(read) in function bark_noise_hybridmp() of libvorbis-1....2020-07-06T20:52:22ZJiangxinStack buffer overflow(read) in function bark_noise_hybridmp() of libvorbis-1.3.6, which is caused by lacking of array length check.I found a stack buffer overflow vul in function bark_noise_hybridmp() of libvorbis-1.3.6 by fuzzing libtheora, the crash sample behaves as follows:
```
(gdb) bt
#0 0x00007ffff6fdfb55 in raise () from /lib64/libc.so.6
#1 0x00007ffff6fe...I found a stack buffer overflow vul in function bark_noise_hybridmp() of libvorbis-1.3.6 by fuzzing libtheora, the crash sample behaves as follows:
```
(gdb) bt
#0 0x00007ffff6fdfb55 in raise () from /lib64/libc.so.6
#1 0x00007ffff6fe1131 in abort () from /lib64/libc.so.6
#2 0x0000000000520a0b in __sanitizer::Abort () at /home/jiangxin/hunter-tool/llvm5/projects/compiler-rt/lib/sanitizer_common/sanitizer_posix_libcdep.cc:146
#3 0x000000000051eb3a in __sanitizer::Die () at /home/jiangxin/hunter-tool/llvm5/projects/compiler-rt/lib/sanitizer_common/sanitizer_termination.cc:59
#4 0x00000000005051a5 in ~ScopedInErrorReport (this=<optimized out>, __in_chrg=<optimized out>) at /home/jiangxin/hunter-tool/llvm5/projects/compiler-rt/lib/asan/asan_report.cc:225
#5 __asan::ReportGenericError (pc=<optimized out>, bp=bp@entry=140737488322736, sp=sp@entry=140737488322728, addr=<optimized out>, is_write=is_write@entry=false, access_size=access_size@entry=4, exp=<optimized out>, exp@entry=0, fatal=<optimized out>, fatal@entry=true) at /home/jiangxin/hunter-tool/llvm5/projects/compiler-rt/lib/asan/asan_report.cc:420
#6 0x0000000000505c03 in __asan::__asan_report_load4 (addr=<optimized out>) at /home/jiangxin/hunter-tool/llvm5/projects/compiler-rt/lib/asan/asan_rtl.cc:133
#7 0x000000000062cc6d in bark_noise_hybridmp (n=256, b=0x61d000000a80, f=0x61d000007c80, noise=0x619000005a80, offset=140, fixed=-1) at psy.c:608
#8 0x000000000062b3fb in _vp_noisemask (p=0x610000000040, logmdct=0x61d000007c80, logmask=0x619000005a80) at psy.c:705
#9 0x000000000069ff59 in mapping0_forward (vb=0x7fffffffd330) at mapping0.c:417
#10 0x00000000006244af in vorbis_analysis (vb=0x7fffffffd330, op=0x0) at analysis.c:46
#11 0x000000000052f14e in fetch_and_process_audio (audio=0x616000000380, audiopage=0x7fffffffd5e0, vo=0x7fffffffceb0, vd=0x7fffffffd260, vb=0x7fffffffd330, audioflag=0) at encoder_example.c:996
#12 0x0000000000536546 in main (argc=5, argv=0x7fffffffdfe8) at encoder_example.c:1754
```
This vul is because of lacking of array len check , and I recommand a patch as follows:
psy.c:
```
602 for (i = 0, x = 0.f;; i++, x += 1.f) {
603
604 lo = b[i] >> 16;
605 if( lo>=0 ) break;
606 hi = b[i] & 0xffff;
607 if(hi>=n || -lo>=n)break;//recommanded patch for this vul
608 tN = N[hi] + N[-lo];
609 tX = X[hi] - X[-lo];
610 tXX = XX[hi] + XX[-lo];
611 tY = Y[hi] + Y[-lo];
612 tXY = XY[hi] - XY[-lo];
```
Note: I need compile libtheora and libvorbis by clang asan and use encoder_example of libtheora to reproduce this vul.
The cmdline to reproduce this vul is like this :
./encoder_example crash_sample xxx.y4m -o out.ogv
The binary encoder_example belongs to libtheora.Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/vorbis/-/issues/2333Infinite loop in _get_prev_page_serial2019-01-28T23:34:17ZStefan LednickyInfinite loop in _get_prev_page_serialWe are using libvorbis 1.3.5 , specifically with Unreal Engine.
We get a rare hang in _get_prev_page_serial. What we see is that _get_next_page returns OV_EOF on ln245 of vorbisfile.c, which then causes us to break out of the inner loop...We are using libvorbis 1.3.5 , specifically with Unreal Engine.
We get a rare hang in _get_prev_page_serial. What we see is that _get_next_page returns OV_EOF on ln245 of vorbisfile.c, which then causes us to break out of the inner loop. The outer loop then seeks back to the beginning, and starts reading again, until we get the OV_EOF again in the inner loop... repeat infinitely.
OV_EOF, and possibly other error codes, should perhaps also return or be somehow handled so that it doesn't result in an infinite loop. I'm also guessing _get_prev_page has the same issue.https://gitlab.xiph.org/xiph/vorbis/-/issues/2332CVE-2017-11333 - The vorbis_analysis_wrote function in lib/block.c in Xiph.Or...2018-03-17T18:07:32ZGuido GüntherCVE-2017-11333 - The vorbis_analysis_wrote function in lib/block.c in Xiph.Org libvorbis 1.3.5 allows remote attackers to cause a denial of service (OOM) via a crafted wav file.Discovered by qflb.wu
See 2nd issue in http://seclists.org/fulldisclosure/2017/Jul/82
Copy paste from there:
```
1.
the vorbis_analysis_wrote function in lib/block.c in Xiph.Org libvorbis 1.3.5 can cause a denial of service(OOM) via a ...Discovered by qflb.wu
See 2nd issue in http://seclists.org/fulldisclosure/2017/Jul/82
Copy paste from there:
```
1.
the vorbis_analysis_wrote function in lib/block.c in Xiph.Org libvorbis 1.3.5 can cause a denial of service(OOM) via a
crafted wav file.
I found this bug when I test Sound eXchange(SoX) 14.4.2 which used the libvorbis library.
./sox libvorbis_1.3.5_OOM.wav out.ogg
/var/log/syslog info:
Jul 13 19:58:05 ubuntu kernel: [] Out of memory: Kill process 44203 (sox) score 364 or sacrifice child
Jul 13 19:58:05 ubuntu kernel: [] Killed process 44203 (sox) total-vm:1831804kB, anon-rss:599932kB, file-rss:40kB
----debug info:----
#0 0x00007ffff5df5e92 in vorbis_analysis_wrote ()
from /usr/local/lib/libvorbis.so.0
#1 0x00007ffff7ba1cba in write_samples (ft=0x611c20, buf=buf@entry=0x0,
len=len@entry=0x0) at vorbis.c:358
#2 0x00007ffff7ba1dc5 in stopwrite (ft=<optimized out>) at vorbis.c:398
#3 0x00007ffff7b58488 in sox_close (ft=0x611c20) at formats.c:1006
#4 0x0000000000405fa8 in cleanup () at sox.c:246
#5 0x0000000000403479 in main (argc=argc@entry=0x3,
argv=argv@entry=0x7fffffffe5e8) at sox.c:3050
#6 0x00007ffff727bec5 in __libc_start_main (main=0x4029c0 <main>, argc=0x3,
argv=0x7fffffffe5e8, init=<optimized out>, fini=<optimized out>,
rtld_fini=<optimized out>, stack_end=0x7fffffffe5d8) at libc-start.c:287
#7 0x0000000000403c65 in _start ()
--------
Program terminated with signal SIGKILL, Killed.
The program no longer exists.
```https://gitlab.xiph.org/xiph/vorbis/-/issues/2331CVE-2017-11735 - The vorbis_block_clear function in lib/block.c in Xiph.Org l...2017-10-09T06:14:10ZGuido GüntherCVE-2017-11735 - The vorbis_block_clear function in lib/block.c in Xiph.Org libvorbis 1.3.5 allows remote attackers to cause a denial of service (NULL pointer dereference and application crash) via a crafted ogg file.Discovered by qflb.wu
See 2nd issue in http://seclists.org/fulldisclosure/2017/Jul/82
Copy paste from there:
```
2.
the vorbis_block_clear function in lib/block.c in Xiph.Org libvorbis 1.3.5 can cause a denial of service(NULL pointer ...Discovered by qflb.wu
See 2nd issue in http://seclists.org/fulldisclosure/2017/Jul/82
Copy paste from there:
```
2.
the vorbis_block_clear function in lib/block.c in Xiph.Org libvorbis 1.3.5 can cause a denial of service(NULL pointer
dereference and application crash) via a crafted ogg file.
I found this bug when I test mp3splt 2.6.2 which used the libvorbis library.
./mp3splt -P -t 0.9 libvorbis_1.3.5_null_pointer_dereference.ogg
----debug info:----
0x00007ffff61752c0 in vorbis_block_clear () from /usr/local/lib/libvorbis.so.0
(gdb) disassemble
Dump of assembler code for function vorbis_block_clear:
0x00007ffff61752a0 <+0>:push %r14
0x00007ffff61752a2 <+2>:mov %rdi,%r14
0x00007ffff61752a5 <+5>:push %r13
0x00007ffff61752a7 <+7>:push %r12
0x00007ffff61752a9 <+9>:push %rbp
0x00007ffff61752aa <+10>:push %rbx
0x00007ffff61752ab <+11>:mov 0xb8(%rdi),%r13
0x00007ffff61752b2 <+18>:callq 0x7ffff616b240 <_vorbis_block_ripcord@plt>
0x00007ffff61752b7 <+23>:mov 0x70(%r14),%rdi
0x00007ffff61752bb <+27>:test %rdi,%rdi
0x00007ffff61752be <+30>:je 0x7ffff61752c5 <vorbis_block_clear+37>
=> 0x00007ffff61752c0 <+32>:callq 0x7ffff616b130 <free@plt>
0x00007ffff61752c5 <+37>:test %r13,%r13
0x00007ffff61752c8 <+40>:je 0x7ffff617530c <vorbis_block_clear+108>
0x00007ffff61752ca <+42>:mov $0x1,%r12d
0x00007ffff61752d0 <+48>:xor %ebx,%ebx
0x00007ffff61752d2 <+50>:jmp 0x7ffff61752df <vorbis_block_clear+63>
0x00007ffff61752d4 <+52>:nopl 0x0(%rax)
0x00007ffff61752d8 <+56>:add $0x1,%ebx
0x00007ffff61752db <+59>:add $0x1,%r12d
0x00007ffff61752df <+63>:movslq %ebx,%rax
---Type <return> to continue, or q <return> to quit---q
Quit
(gdb) i r
rax 0x22
rbx 0x61fca06421664
rcx 0x00
rdx 0x7ffff7ba6778140737349576568
rsi 0x00
rdi 0x80128
rbp 0x7fffffffd4700x7fffffffd470
rsp 0x7fffffffd4000x7fffffffd400
r8 0x746e656d75636f008389754676633104128
r9 0x6143506374224
r10 0x7fffffffd1f0140737488343536
r11 0x7ffff61752a0140737322111648
r12 0x6128506367312
r13 0x00
r14 0x6205606423904
r15 0x7ffff7bcf146140737349742918
rip 0x7ffff61752c00x7ffff61752c0 <vorbis_block_clear+32>
eflags 0x202[ IF ]
cs 0x3351
ss 0x2b43
ds 0x00
es 0x00
fs 0x00
---Type <return> to continue, or q <return> to quit---
gs 0x00
(gdb) ni
Program received signal SIGSEGV, Segmentation fault.
__GI___libc_free (mem=0x80) at malloc.c:2929
2929malloc.c: No such file or directory.
(gdb) bt
#0 __GI___libc_free (mem=0x80) at malloc.c:2929
#1 0x00007ffff61752c5 in vorbis_block_clear ()
from /usr/local/lib/libvorbis.so.0
#2 0x00007ffff65ac5ae in splt_ogg_v_free (oggstate=0x61fca0) at ogg.c:162
#3 0x00007ffff65ace0b in splt_ogg_info (in=<optimized out>,
state=state@entry=0x60ddb0, error=error@entry=0x7fffffffdbf0) at ogg.c:545
#4 0x00007ffff65acf75 in splt_ogg_get_info (state=state@entry=0x60ddb0,
file_input=<optimized out>, error=error@entry=0x7fffffffdbf0) at ogg.c:108
#5 0x00007ffff65ae6c7 in splt_pl_init (state=0x60ddb0, error=0x7fffffffdbf0)
at ogg.c:1482
#6 0x00007ffff7bcac16 in splt_tp_get_original_tags_and_append (
error=0x7fffffffdbf0, state=0x60ddb0) at tags_parser.c:545
#7 splt_tp_process_original_tags_variable (tpu=tpu@entry=0x61f800,
state=state@entry=0x60ddb0, error=error@entry=0x7fffffffdbf0,
set_original_tags=1) at tags_parser.c:514
#8 0x00007ffff7bcb4d1 in splt_tp_process_tag_variable (error=0x7fffffffdbf0,
state=0x60ddb0, tpu=0x61f800, end_paranthesis=0x7ffff7bcf14c "]",
tag_variable_start=0x7ffff7bcf146 "o,@N=1]") at tags_parser.c:363
#9 splt_tp_process_tags (error=0x7fffffffdbf0, state=0x60ddb0, tpu=0x61f800,
tags=0x7ffff7bcf143 "%[@o,@N=1]") at tags_parser.c:293
#10 splt_tp_put_tags_from_string (state=state@entry=0x60ddb0,
tags=tags@entry=0x7ffff7bcf143 "%[@o,@N=1]",
error=error@entry=0x7fffffffdbf0) at tags_parser.c:192
---Type <return> to continue, or q <return> to quit---
#11 0x00007ffff7bbb4f3 in mp3splt_split (state=state@entry=0x60ddb0)
at mp3splt.c:1232
#12 0x0000000000403320 in main (argc=<optimized out>,
orig_argv=<optimized out>) at mp3splt.c:872
(gdb)
--------------------
int vorbis_block_clear(vorbis_block *vb){
int i;
vorbis_block_internal *vbi=vb->internal;
_vorbis_block_ripcord(vb);
if(vb->localstore)_ogg_free(vb->localstore); <========
if(vbi){
for(i=0;i<PACKETBLOBS;i++){
oggpack_writeclear(vbi->packetblob[i]);
if(i!=PACKETBLOBS/2)_ogg_free(vbi->packetblob[i]);
}
_ogg_free(vbi);
}
memset(vb,0,sizeof(*vb));
return(0);
}
```https://gitlab.xiph.org/xiph/vorbis/-/issues/2329(CVE-2017-14633)an out-of-bound array read vul in function mapping0_forward()...2017-12-11T08:15:06ZJiangxin(CVE-2017-14633)an out-of-bound array read vul in function mapping0_forward() in libvorbis 1.3.5```
╭─root@linux-jiangxin in /home/jiangxin/experiment/fuzz/AFL/target/libtheora-1.1.1/examples
╰$ gdb encoder_example
GNU gdb (GDB) 7.9
Copyright (C) 2015 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 ...```
╭─root@linux-jiangxin in /home/jiangxin/experiment/fuzz/AFL/target/libtheora-1.1.1/examples
╰$ gdb encoder_example
GNU gdb (GDB) 7.9
Copyright (C) 2015 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-unknown-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from encoder_example...done.
(gdb) run ../fuzz/crash-oob-read xxx.y4m
Program received signal SIGSEGV, Segmentation fault.
0x00000000005754f9 in mapping0_forward (vb=<optimized out>) at mapping0.c:501
500 if(ci->floor_type[info->floorsubmap[submap]]!=1)return(-1);
(gdb) bt
#0 0x00000000005754f9 in mapping0_forward (vb=<optimized out>) at mapping0.c:500
#1 0x00000000004d3512 in vorbis_analysis (vb=vb@entry=0x7fffffffdbe0, op=op@entry=0x0) at analysis.c:47
#2 0x0000000000410926 in fetch_and_process_audio (audio=0x83b010, audiopage=audiopage@entry=0x7fffffffda40, vo=vo@entry=0x7fffffffde40, vd=vd@entry=0x7fffffffdb50, vb=vb@entry=0x7fffffffdbe0, audioflag=audioflag@entry=0) at encoder_example.c:996
#3 0x0000000000405a9b in main (argc=<optimized out>, argv=<optimized out>) at encoder_example.c:1754
(gdb) i r
rax 0x84b420 8696864
rbx 0x1d3c1a0 30654880
rcx 0x100 256
rdx 0x1e332a0 31666848
rsi 0x1e32e70 31665776
rdi 0x85f000 8777728
rbp 0x7fffffffc850 0x7fffffffc850
rsp 0x7fffffff9ee0 0x7fffffff9ee0
r8 0x1a9b500 27899136
r9 0x8494f0 8688880
r10 0x3e9b02c6 1050346182
r11 0xfe 254
r12 0x1a9b900 27900160
r13 0x84e0e4 8708324
r14 0x84cc00 8702976
r15 0x1b93728 28915496
rip 0x5754f9 0x5754f9 <mapping0_forward+5737>
eflags 0x10246 [ PF ZF IF RF ]
cs 0x33 51
ss 0x2b 43
ds 0x0 0
es 0x0 0
fs 0x0 0
gs 0x0 0
(gdb) x/i $pc
=> 0x5754f9 <mapping0_forward+5737>: cmpl $0x1,0x528(%r9,%r10,4)
(gdb) x/128xb $r9+$r10*4+0x528
0xfaf0a530: Cannot access memory at address 0xfaf0a530
```https://gitlab.xiph.org/xiph/vorbis/-/issues/2328(CVE-2017-14632)call oggpack_writeclear() with uninitialized stack var opb in...2018-05-09T21:59:56ZJiangxin(CVE-2017-14632)call oggpack_writeclear() with uninitialized stack var opb in function vorbis_analysis_headerout() when vi->channels<=0 in libvorbis 1.3.5```
int vorbis_analysis_headerout(vorbis_dsp_state *v,
577 vorbis_comment *vc,
578 ogg_packet *op,
579 ogg_packet *op_comm,
580 ...```
int vorbis_analysis_headerout(vorbis_dsp_state *v,
577 vorbis_comment *vc,
578 ogg_packet *op,
579 ogg_packet *op_comm,
580 ogg_packet *op_code){
581 int ret=OV_EIMPL;
582 vorbis_info *vi=v->vi;
583 oggpack_buffer opb;
584 private_state *b=v->backend_state;
585
586 if(!b||vi->channels<=0){
587 ret=OV_EFAULT;
588 goto err_out;
589 }
...
639 err_out:
640 memset(op,0,sizeof(*op));
641 memset(op_comm,0,sizeof(*op_comm));
642 memset(op_code,0,sizeof(*op_code));
643
644 if(b){
645 oggpack_writeclear(&opb);
646 if(b->header)_ogg_free(b->header);
647 if(b->header1)_ogg_free(b->header1);
648 if(b->header2)_ogg_free(b->header2);
649 b->header=NULL;
650 b->header1=NULL;
651 b->header2=NULL;
652 }
as shown above, if vi->channels<=0 and b!=NULL then func goes to err_out with opb uninitialized, but before calling oggpack_writeclear, it only check if(b),so it will ultimately free a uninitialized memory in oggpack_writeclear:
250 void oggpack_writeclear(oggpack_buffer *b){
251 if(b->buffer)_ogg_free(b->buffer);
252 memset(b,0,sizeof(*b));
253 }
This vul may lead to a DOS or Remote Code Execution in products using libvorbis 1.3.5(latest version).
By the way, I found 8 years ago this function has been found a similar vul :https://bugzilla.mozilla.org/show_bug.cgi?id=550184
while cause of no check of if b=NULL before calling oggpack_writeclear. This time , it is because of incorrect check while no considering if vi->channels<=0.
To reproduce this vul, compile libtheora 1.1.1 libvorbis 1.3.5 libogg 1.3.2 ,then run as below:
╭─root@linux-jiangxin in /home/jiangxin/experiment/fuzz/AFL/target/libtheora-1.1.1/fuzz
╰$ gdb ../examples/encoder_example
GNU gdb (GDB) 7.9
Copyright (C) 2015 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-unknown-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from ../examples/encoder_example...done.
(gdb) run out/Master/crashes/id:000000,sig:06,src:000000,op:flip1,pos:22 xxx.y4m
Starting program: /home/jiangxin/experiment/fuzz/AFL/target/libtheora-1.1.1/examples/encoder_example out/Master/crashes/id:000000,sig:06,src:000000,op:flip1,pos:22 xxx.y4m
File out/Master/crashes/id:000000,sig:06,src:000000,op:flip1,pos:22 is 16 bit 0 channel 44100 Hz RIFF WAV audio.
File xxx.y4m is 176x144 29.97 fps mono video.
*** glibc detected *** /home/jiangxin/experiment/fuzz/AFL/target/libtheora-1.1.1/examples/encoder_example: munmap_chunk(): invalid pointer: 0x00007fffffffdb30 ***
======= Backtrace: =========
/lib64/libc.so.6(+0x76628)[0x7ffff7864628]
/home/jiangxin/experiment/fuzz/AFL/target/libtheora-1.1.1/examples/encoder_example[0x4a4505]
/home/jiangxin/experiment/fuzz/AFL/target/libtheora-1.1.1/examples/encoder_example[0x504090]
/home/jiangxin/experiment/fuzz/AFL/target/libtheora-1.1.1/examples/encoder_example[0x40535d]
/lib64/libc.so.6(__libc_start_main+0xe6)[0x7ffff780cc36]
/home/jiangxin/experiment/fuzz/AFL/target/libtheora-1.1.1/examples/encoder_example[0x40a039]
======= Memory map: ========
00400000-0063a000 r-xp 00000000 08:08 6452963 /home/jiangxin/experiment/fuzz/AFL/target/libtheora-1.1.1/examples/encoder_example
00839000-0083a000 r--p 00239000 08:08 6452963 /home/jiangxin/experiment/fuzz/AFL/target/libtheora-1.1.1/examples/encoder_example
0083a000-0083b000 rw-p 0023a000 08:08 6452963 /home/jiangxin/experiment/fuzz/AFL/target/libtheora-1.1.1/examples/encoder_example
0083b000-008e6000 rw-p 00000000 00:00 0 [heap]
7ffff75d7000-7ffff75ed000 r-xp 00000000 08:07 155653 /usr/local/lib64/libgcc_s.so.1
7ffff75ed000-7ffff77ec000 ---p 00016000 08:07 155653 /usr/local/lib64/libgcc_s.so.1
7ffff77ec000-7ffff77ed000 r--p 00015000 08:07 155653 /usr/local/lib64/libgcc_s.so.1
7ffff77ed000-7ffff77ee000 rw-p 00016000 08:07 155653 /usr/local/lib64/libgcc_s.so.1
7ffff77ee000-7ffff795c000 r-xp 00000000 08:07 131081 /lib64/libc-2.11.3.so
7ffff795c000-7ffff7b5b000 ---p 0016e000 08:07 131081 /lib64/libc-2.11.3.so
7ffff7b5b000-7ffff7b5f000 r--p 0016d000 08:07 131081 /lib64/libc-2.11.3.so
7ffff7b5f000-7ffff7b60000 rw-p 00171000 08:07 131081 /lib64/libc-2.11.3.so
7ffff7b60000-7ffff7b65000 rw-p 00000000 00:00 0
7ffff7b65000-7ffff7bc0000 r-xp 00000000 08:07 131089 /lib64/libm-2.11.3.so
7ffff7bc0000-7ffff7dbf000 ---p 0005b000 08:07 131089 /lib64/libm-2.11.3.so
7ffff7dbf000-7ffff7dc0000 r--p 0005a000 08:07 131089 /lib64/libm-2.11.3.so
7ffff7dc0000-7ffff7dde000 rw-p 0005b000 08:07 131089 /lib64/libm-2.11.3.so
7ffff7dde000-7ffff7dfd000 r-xp 00000000 08:07 131074 /lib64/ld-2.11.3.so
7ffff7f24000-7ffff7fc1000 rw-p 00000000 00:00 0
7ffff7fc8000-7ffff7ff8000 rw-p 00000000 00:00 0
7ffff7ff8000-7ffff7ffa000 r--p 00000000 00:00 0 [vvar]
7ffff7ffa000-7ffff7ffc000 r-xp 00000000 00:00 0 [vdso]
7ffff7ffc000-7ffff7ffd000 r--p 0001e000 08:07 131074 /lib64/ld-2.11.3.so
7ffff7ffd000-7ffff7ffe000 rw-p 0001f000 08:07 131074 /lib64/ld-2.11.3.so
7ffff7ffe000-7ffff7fff000 rw-p 00000000 00:00 0
7ffffffde000-7ffffffff000 rw-p 00000000 00:00 0 [stack]
ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0 [vsyscall]
OggSa8W!۰ہ*theora
°u0迵@
Program received signal SIGABRT, Aborted.
0x00007ffff7820b55 in raise () from /lib64/libc.so.6
(gdb) bt
#0 0x00007ffff7820b55 in raise () from /lib64/libc.so.6
#1 0x00007ffff7822131 in abort () from /lib64/libc.so.6
#2 0x00007ffff785ee0f in __libc_message () from /lib64/libc.so.6
#3 0x00007ffff7864628 in malloc_printerr () from /lib64/libc.so.6
#4 0x00000000004a4505 in oggpack_writeclear (b=b@entry=0x7fffffffda10) at bitwise.c:251
#5 0x0000000000504090 in vorbis_analysis_headerout (v=v@entry=0x7fffffffdcb0, vc=vc@entry=0x7fffffffdb50, op=op@entry=0x7fffffffdba0, op_comm=op_comm@entry=0x7fffffffdbd0, op_code=op_code@entry=0x7fffffffdc00) at info.c:645
#6 0x000000000040535d in main (argc=<optimized out>, argv=<optimized out>) at encoder_example.c:1688
(gdb) detach
files attached:
weird, I can not attach file here, so if you need please contact me for the the crash sample.
```
This issue has been assigned a CVE number :CVE-2017-14632
https://gitlab.xiph.org/xiph/vorbis/-/issues/2327vorbisfile free of uninitialized memory if seek fails2019-01-28T23:01:57ZGitlab Botvorbisfile free of uninitialized memory if seek failsIn vorbisfile.c, it is possible for ov_raw_seek to free some uninitialized memory (and therefore crash) if seek fails. I attach a patch to fix this bug.
This was originally discovered by an SFML user in this bug, and I investigated it a...In vorbisfile.c, it is possible for ov_raw_seek to free some uninitialized memory (and therefore crash) if seek fails. I attach a patch to fix this bug.
This was originally discovered by an SFML user in this bug, and I investigated it a bit more:
https://github.com/SFML/SFML/issues/1241Thomas DaedeThomas Daedehttps://gitlab.xiph.org/xiph/vorbis/-/issues/2271vorbis git repository missing release markers2017-11-01T04:49:44ZJacob Lifshayvorbis git repository missing release markersThe vorbis git repository should have branches or tags to indicate which commits are the releases. This makes it difficult to use as a submodule.The vorbis git repository should have branches or tags to indicate which commits are the releases. This makes it difficult to use as a submodule.Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/vorbis/-/issues/2221vorbis_comment_add_tag() crash: very large alloca()2017-11-01T04:49:44Zi80andvorbis_comment_add_tag() crash: very large alloca()While transcoding several MP3s via GStreamer on OSX with libvorbis 1.3.5, I encountered a consistent segmentation fault in vorbis_comment_add_tag().
GStreamer passes a very large "contents" argument for these files. vorbis_comment_add_t...While transcoding several MP3s via GStreamer on OSX with libvorbis 1.3.5, I encountered a consistent segmentation fault in vorbis_comment_add_tag().
GStreamer passes a very large "contents" argument for these files. vorbis_comment_add_tag() allocates the comment using alloca(), resulting in a stack overflow.
Replacing alloca() with _ogg_malloc() (and adding a corresponding _ogg_free()) resolves the crash.Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/vorbis/-/issues/2142_initial_pcmoffset uses error codes from vorbis_packet_blocksize in arithmetics2017-11-01T04:49:44ZMartin Steghöfer_initial_pcmoffset uses error codes from vorbis_packet_blocksize in arithmeticsWhile working on #2140, I realized that the function `_initial_pcmoffset` doesn't handle negative values (error codes) returned by `vorbis_packet_blocksize` properly. It simply uses the returned value in an arithmetic expression, regardl...While working on #2140, I realized that the function `_initial_pcmoffset` doesn't handle negative values (error codes) returned by `vorbis_packet_blocksize` properly. It simply uses the returned value in an arithmetic expression, regardless the sign - which leads to an incorrect result. In change, the functions `ov_raw_seek` and `ov_pcm_seek` seem to skip the current packet, if `vorbis_packet_blocksize` returns a negative value.
In the comments of #2140, tterribe suggested a fix that I'm attaching as patch, but couldn't test yet.Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/vorbis/-/issues/2140"Null pointer dereference" [forwarded from Debian #774516]2017-11-01T04:49:44ZMartin Steghöfer"Null pointer dereference" [forwarded from Debian #774516]I'm forwarding the bug 774516 (https://bugs.debian.org/774516) from the Debian bug tracker, so I can discuss with you the fix I'd propose.
----
Original report from Jakub Wilk <jwilk@debian.org>:
Package: vorbis-tools
Version: 1.4.0-6...I'm forwarding the bug 774516 (https://bugs.debian.org/774516) from the Debian bug tracker, so I can discuss with you the fix I'd propose.
----
Original report from Jakub Wilk <jwilk@debian.org>:
Package: vorbis-tools
Version: 1.4.0-6
Usertags: afl
Both oggdec and ogg123 crash on the attached file, trying to dereference
null pointer:
$ oggdec crash.ogg
oggdec from vorbis-tools 1.4.0
Segmentation fault
$ ogg123 crash.ogg
Audio Device: Advanced Linux Sound Architecture (ALSA) output
Segmentation fault
Backtrace:
#0 0xf7f925a8 in vorbis_packet_blocksize (vi=0x804d2f0, op=0xffff910c) at synthesis.c:168
#1 0xf7fb6b4d in _initial_pcmoffset (vf=0xffff92cc, vi=0x804d2f0) at vorbisfile.c:440
#2 0xf7fb8ec0 in _open_seekable2 (vf=0xffff92cc) at vorbisfile.c:625
#3 0xf7fb9117 in _ov_open2 (vf=0xffff92cc) at vorbisfile.c:941
#4 ov_open_callbacks (f=0x804d020, vf=0xffff92cc, initial=0x0, ibytes=0, callbacks=...) at vorbisfile.c:997
#5 0x0804977a in decode_file (in=0x804d020, out=0xffff9098, out@entry=0x804d188, infile=0xffffd88d "crash.ogg", outfile=0x804d008 "crash.wav") at oggdec.c:265
#6 0x08048d5f in main (argc=2, argv=0xffffd6b4) at oggdec.c:455
This bug was found using American fuzzy lop:
https://packages.debian.org/experimental/afl
-- System Information:
Debian Release: 8.0
APT prefers unstable
APT policy: (990, 'unstable'), (500, 'experimental')
Architecture: i386 (x86_64)
Foreign Architectures: amd64
Kernel: Linux 3.2.0-4-amd64 (SMP w/2 CPU cores)
Locale: LANG=C, LC_CTYPE=pl_PL.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)
Versions of packages vorbis-tools depends on:
ii libao4 1.1.0-3
ii libc6 2.19-13
ii libcurl3-gnutls 7.38.0-3
ii libflac8 1.3.0-3
ii libogg0 1.3.2-1
ii libspeex1 1.2~rc1.2-1
ii libvorbis0a 1.3.4-2
ii libvorbisenc2 1.3.4-2
ii libvorbisfile3 1.3.4-2
--
Jakub WilkMonty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/vorbis/-/issues/2139libvorbis-1.3.4 misdecodes streams with single-symbol codebooks2017-11-01T04:49:44ZAndrew Churchlibvorbis-1.3.4 misdecodes streams with single-symbol codebooksAccording to the Vorbis specification (https://xiph.org/vorbis/doc/Vorbis_I_spec.html), "a codebook with a single used entry ... consists of a single codework of zero bits and 'reading' a value out of such a codebook always returns the s...According to the Vorbis specification (https://xiph.org/vorbis/doc/Vorbis_I_spec.html), "a codebook with a single used entry ... consists of a single codework of zero bits and 'reading' a value out of such a codebook always returns the single used value and sinks zero bits". However, libvorbis-1.3.4 does not follow this requirement, instead sinking a nonzero number of bits (presumably the number specified in the codebook). See the attached sample file.
I will note that the reference encoder does not seem to generate single-symbol codebooks, and the specification is unclear on how they should be encoded (since the bitstream format does not allow one to specify a code length of zero bits). However, I've seen files in the wild which do in fact contain such a codebook, perhaps as a result of some sort of external codebook optimizer.
The attached "sample.ogg" file was created from "original.ogg" by modifying the codebook at index 20 (file offset 0x503 + 1 bit; 18 symbols, of which only symbol 9 of length 3 bits is used) so all unused symbols are excluded from the Huffman decision tree, then deleting the 3 bits which encoded that symbol at the two locations it was used, file offsets 0x3117 + 4 bits and 0x3402 + 6 bits.Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/vorbis/-/issues/2120CHANGES changelog for libvorbis not updated since libvorbis 1.3.32020-06-10T22:01:44ZTim SmallCHANGES changelog for libvorbis not updated since libvorbis 1.3.3The CHANGES file for libvorbis 1.3.4 (and also the version in git at the time of writing) only includes changes up to 1.3.3 - i.e. no entries for the 1.3.4 release are present.The CHANGES file for libvorbis 1.3.4 (and also the version in git at the time of writing) only includes changes up to 1.3.3 - i.e. no entries for the 1.3.4 release are present.https://gitlab.xiph.org/xiph/vorbis/-/issues/2079tagcompare() uses toupper() and is sensitive to the current locale2019-02-02T04:30:06ZDavid Kingtagcompare() uses toupper() and is sensitive to the current localeI use libvorbis in EasyTAG to read Vorbis comments from Ogg files, and came across some code that resets the locale to the C locale before calling vorbis_comment_query_count() or vorbis_comment_query(). This avoids a problem where, if th...I use libvorbis in EasyTAG to read Vorbis comments from Ogg files, and came across some code that resets the locale to the C locale before calling vorbis_comment_query_count() or vorbis_comment_query(). This avoids a problem where, if the user's locale is (for example) Turkish, the dotted lower-case i 'i' is transformed to the dotted upper-case i 'İ', rather than the expected dotless upper-case i 'I'. This causes problems for tag names with 'i' characters in the Turkish locale, and maybe there are other examples too.
It would be nice if tagcompare() used a locale-insensitive upper-casing function, so that I do not have to do this in my application (ignoring the fact that calling setlocale() in an application which uses threads is asking for trouble).Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/vorbis/-/issues/2078Invalid memory access with samplingrate==02017-11-01T04:49:44ZMartin SteghöferInvalid memory access with samplingrate==0I am forwarding this issue from the Debian bug tracker: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=716613
The Mayhem software detected a crash when passing a specially crafted FLAC file to oggenc. I've examined the problem furthe...I am forwarding this issue from the Debian bug tracker: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=716613
The Mayhem software detected a crash when passing a specially crafted FLAC file to oggenc. I've examined the problem further and found out that the problem is that the flac reader provides an input stream with a sampling rate of 0. This is something that neither oggenc itself nor libvorbisenc can cope with. The oggenc executable crashes with SIGFPE (division by the sampling rate in the statistics => division by 0) and libvorbisenc accesses invalid memory during the initialization.
While the oggenc crash doesn't affect the usability much (there is nothing valid to encode anyway in a file with sampling rate 0), libvorbisenc's access to invalid memory has the potential to either crash the whole downstream application with SIGSEGV or even be a security issue (although my preliminary examination didn't show any sign of exploitability).
The latest versions of vorbis-tools and libvorbis (and probably many earlier versions) are affected (I'm reporting this here because these version numbers don't appear in the TRAC version dropdown):
* libvorbis: 1.3.4
* vorbis-tools: 1.4.0
Please find attached the patches that we used in Debian. They add sanity checks to both the oggenc executable and the initialization routines of libvorbis.Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/vorbis/-/issues/2060Typos in Vorbis I specification2017-11-01T04:49:44ZstefanTypos in Vorbis I specificationWhile reading through the [Vorbis I specification](https://xiph.org/vorbis/doc/Vorbis_I_spec.pdf), I discovered two minor typos:
*Section 4.3.8*
_"window\_blocksize(previous\_window)/4+window\_blocksize(current\_window)/4"_
should read
...While reading through the [Vorbis I specification](https://xiph.org/vorbis/doc/Vorbis_I_spec.pdf), I discovered two minor typos:
*Section 4.3.8*
_"window\_blocksize(previous\_window)/4+window\_blocksize(current\_window)/4"_
should read
_"window_blocksize(previous_window)/4+window_blocksize(current_window)/4"_
(remove the backslashes)
*Section 10.1*
_"The vector [floor1_inverse_dB_table] is a 256 element static lookup table consiting of the following values (read left to right then top to bottom):"_
_"consiting"_ should read _"consisting"_
It would mean a lot to me if you have time to fix them.https://gitlab.xiph.org/xiph/vorbis/-/issues/2038Vorbis borks a pure 440Hz sine wave at the highest quality level2017-11-01T04:49:44ZArtem S. TashkinovVorbis borks a pure 440Hz sine wave at the highest quality levelA test case:
```
oggenc -q10 *wav
WARNING: quality setting too high, setting to maximum quality.
Opening with wav module: WAV file reader
Encoding "01_440hz Tone.wav" to
"01_440hz Tone.ogg"
at quality 10.00
[ 99.9%] [ 0...A test case:
```
oggenc -q10 *wav
WARNING: quality setting too high, setting to maximum quality.
Opening with wav module: WAV file reader
Encoding "01_440hz Tone.wav" to
"01_440hz Tone.ogg"
at quality 10.00
[ 99.9%] [ 0m00s remaining] /
Done encoding file "01_440hz Tone.ogg"
File length: 14m 42.0s
Elapsed time: 0m 09.2s
Rate: 95.4935
Average bitrate: 26.0 kb/s
```
Components versions:
```
$ rpm -qa | grep vorbis
libvorbis-1.3.4-2.el6.i686
libvorbis-devel-1.3.4-2.el6.i686
vorbis-tools-1.4.0-16.el6.i686
```Monty MontgomeryMonty Montgomery