[xine-bugs] [ xine-Bugs-1603458 ] Probably buffer overrun exploit in Real Media input plugin

[SourceForge.net <no...@so...>]

Bugs item #1603458, was opened at 2006-11-27 03:41
Message generated for change (Comment added) made by dgp85
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=109655&aid=1603458&group_id=9655

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: v1.1.2
>Status: Closed
>Resolution: Fixed
Priority: 5
Private: No
Submitted By: Roland Kay (rkay)
>Assigned to: Diego Pettenò (dgp85)
Summary: Probably buffer overrun exploit in Real Media input plugin

Initial Comment:

In the following code fragment from the Real Media input plugin "rulematches" is a static buffer with enough space for 16 ints. However, asmrp_match() does not take a parameter giving the size of the buffer and performs no bounds checking. This can be seen by examining asmrp_eval().

It would be possible, in principle, for a malicious server to create a rulebook that would cause arbitrary data to overwrite the stack. Creating a viable exploit would be rather tedious, but a DSO attack would be trivial.

>8--------------------------------------------8<
src/input/libreal/real.c:468

  for (i=0; i<desc->stream_count; i++) {

    int j=0;
    int n;
    char b[64];
    int rulematches[16];

    lprintf("calling asmrp_match with:\n%s\n%u", desc->stream[i]->asm_rule_book, bandwidth);

    n=asmrp_match(desc->stream[i]->asm_rule_book, bandwidth, rulematches);


  

----------------------------------------------------------------------

>Comment By: Diego Pettenò (dgp85)
Date: 2006-11-29 20:34

Message:
Logged In: YES 
user_id=60011
Originator: NO

Thanks both of you for reporting and for the patch, I've committed this to
CVS now.


----------------------------------------------------------------------

Comment By: JW (jw203198)
Date: 2006-11-28 02:57

Message:
Logged In: YES 
user_id=835230
Originator: NO

If you are finding a large number then perhaps you should check out a copy
of the code from CVS (anybody can do this), make your changes, and convert
them into patches when you feel like you have found enough of them.  You
don't have to have full CVS access to do that (use cvs rdiff, or something
similar).

Then again, since some of the code looks extremely sloppy and should never
have been committed to CVS, perhaps annoying multiple individual patches or
bug reports might not be such a bad idea after all.

Anyhow I usually ignore CVS methods completely and simply do:
    cp x.c x.c.jw
    vi x.c
and compile, test, etc then when done:
    find . -name \*.jw | while read f
    do
        diff -Nau $f ${f%.jw}
    done >xine-jw.patch
Mainly because I mostly find myself patching rpm source.


----------------------------------------------------------------------

Comment By: Roland Kay (rkay)
Date: 2006-11-28 02:19

Message:
Logged In: YES 
user_id=1477903
Originator: YES

Given the triviality of the fix, I thought it more expedient for someone
with direct CVS access to update the code directly. I've been finding
quite a few of these kinds of issues and, since I'm maintaining a separate
code base, creating patches is not an insignificant amount of work.
However, if I notice problems I think it important that I notify the
authors. Thanks for supplying a patch; hopefully, someone can apply it.

----------------------------------------------------------------------

Comment By: JW (jw203198)
Date: 2006-11-27 04:06

Message:
Logged In: YES 
user_id=835230
Originator: NO

I dunno .. but if you can understand the code enough to figure a possible
problem wouldn't it be more expedient to just submit a patch?  The fix is
quite trivial.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=109655&aid=1603458&group_id=9655