Hi guys,

Maybe this is amazing that you can almost find anything in the Internet, However always there are some exceptions.
If you search google for "how to analyze a vulnerability", You'll get nothing.

So I want to discuss on some general methods or methodologies for analyzing a vulnerability, And I'm pretty sure some of you guys like it.

If you encounter a common stack or heap based buffer overflow vulnerability, analyzing will be quite easy.
However, sometimes you encounter some challenging vulnerabilities like this:

VLC Vulnerabilities handling .AMV and .NSV files:
http://www.coresecurity.com/content/vlc-vulnerabilities-amv-nsv-files

A sample:
http://samples.libav.org/samples/nsv/64vp3.nsv

just change value at 0x0b to 0x0e to 0XFFFFFFFF and vlc will crash.

Source code of VLC 1.1.7:
http://download.videolan.org/pub/videolan/vlc/1.1.7/vlc-1.1.7.tar.bz2

Win32 compiled version:
http://download.videolan.org/pub/videolan/vlc/1.1.7/win32/vlc-1.1.7-win32.7z

To be honest, I tried to analyze it, but i failed, even by reading the patch:

--- a/src/video_output/video_output.c
+++ b/src/video_output/video_output.c
@@ -297,7 +297,7 @@ vout_thread_t * vout_Create( vlc_object_t *p_parent, video_format_t *p_fmt )
char *psz_parser;
char *psz_name;

- if( i_width <= 0 || i_height <= 0 )
+ if( i_width <= 0 || i_height <= 0 || i_width > 8192 || i_height > 8192 )
return NULL;

vlc_ureduce( &p_fmt->i_sar_num, &p_fmt->i_sar_den,

Could anybody find out what is the root of this vulnerability?
Believe me, It's not easy, however if you do some analysis, just let us know the result and your methodology.
We can discuss more to reach a general methodology.

static

Hi there,

I ve been searching boards/threads where people exchange their approaches and methods in vulnerability research - and more to my interest: finding vulnerabilities via RCE rather than fuzzing.

There s often specific problem related topics and discussion, but the methods people use in general seem to be worth hiding. I guess since a variety on methods result in more efficient reversing people dont want to lose their edge.
Microsofts main researcher/hacker gave an excellent talk on how he analyzed stuxnet. Talk is on youtube and he revealed his methods and the need to be time efficient in order to beat other companys in the research.

Working in a group can slow one down - depending on the group. Having a thread/index of RCE methods contributed by people would be a great timesaver/boost in learning though.
Hope there is one already and i just havent found it - otherwise lets make one ?!

RickD

Finding vuls via RCE can be extremely time-consuming and boring.
have a look to file specifications and try to find where interesting things like length, width and ... are processed by application (more on it later).
finding vuls via source code auditing is fun and full of lessons if you match source code with disassembly.
I guess you should write many plugins to speedup common duties.

can you give a link to mentioned youtube clip?

It seems VLC vulnerability was harder than my&your expectation.

static.

He probably meant Bruce Dang's CCC talk on Stuxnet code, here it is http://www.youtube.com/watch?v=rOwMW6agpTI.

Vulnerabilities are just software bugs, but with security implications.

In your case:
- if( i_width <= 0 || i_height <= 0 )
+ if( i_width <= 0 || i_height <= 0 || i_width > 8192 || i_height > 8192 )

provides enough information -- there's probably an integer overflow when dealing with i_width and i_height. You should check where and how these variables are used.

Indeed. Look for a memory allocation of i_width+1 or i_height+1 or something similar.

With an open source project like this, I think you can use something like gcov. When you compile it with gcc/gcov, it includes source information so you can do coverage analysis on the source code. I would give that a shot and see what you can glean from it.