Skip to content

F
ffmpeg.wasm-core
Switch branch/tag
  1. 05 Jun, 2017 10 commits
    • Rostislav Pehlivanov's avatar
      vorbisenc: signal samples to skip · 7fc1be9a
      Rostislav Pehlivanov authored 
      The encoder never actually signalled how many samples to skip.
Signed-off-by: 's avatarRostislav Pehlivanov <atomnuker@gmail.com>
      7fc1be9a
    • Tyler Jones's avatar
      avcodec/vorbisenc: Use a bufqueue in encoding with smaller lengths · 29c13fed
      Tyler Jones authored 
      Switching the vorbis encoder to use a buffer queue for input frames allows
saving lookahead samples more easily and safely for psychoacoustic systems,
requiring less pointer arithmetic in the case of transient windows.
      29c13fed
    • Tyler Jones's avatar
      avcodec/vorbisenc: Include bufqueue and afqueue · 25260b51
      Tyler Jones authored
      25260b51
    • Tyler Jones's avatar
      avcodec/vorbisenc: Use fdsp for applying windows · 79941602
      Tyler Jones authored 
      Using fdsp improves readability and allows using architecture-specific
optimizations.
Signed-off-by: 's avatarTyler Jones <tdjones879@gmail.com>
      79941602
    • Tyler Jones's avatar
      avcodec/vorbisenc: Include fdsp · 610864dc
      Tyler Jones authored 
      Signed-off-by: 's avatarTyler Jones <tdjones879@gmail.com>
      610864dc
    • Michael Niedermayer's avatar
      avformat/hls: Check local file extensions · 189ff421
      Michael Niedermayer authored 
      This reduces the attack surface of local file-system
information leaking.

It prevents the existing exploit leading to an information leak. As
well as similar hypothetical attacks.

Leaks of information from files and symlinks ending in common multimedia extensions
are still possible. But files with sensitive information like private keys and passwords
generally do not use common multimedia filename extensions.
It does not stop leaks via remote addresses in the LAN.

The existing exploit depends on a specific decoder as well.
It does appear though that the exploit should be possible with any decoder.
The problem is that as long as sensitive information gets into the decoder,
the output of the decoder becomes sensitive as well.
The only obvious solution is to prevent access to sensitive information. Or to
disable hls or possibly some of its feature. More complex solutions like
checking the path to limit access to only subdirectories of the hls path may
work as an alternative. But such solutions are fragile and tricky to implement
portably and would not stop every possible attack nor would they work with all
valid hls files.

Developers have expressed their dislike / objected to disabling hls by default as well
as disabling hls with local files. There also where objections against restricting
remote url file extensions. This here is a less robust but also lower
inconvenience solution.
It can be applied stand alone or together with other solutions.
limiting the check to local files was suggested by nevcairiel

This recommits the security fix without the author name joke which was
originally requested by Nicolas.

Found-by: Emil Lerner and Pavel Cheremushkin
Reported-by: 's avatarThierry Foucu <tfoucu@google.com>
Signed-off-by: 's avatarMichael Niedermayer <michael@niedermayer.cc>
      189ff421
    • Michael Niedermayer's avatar
      Revert "avformat/hls: Check local file extensions" · c0702ab8
      Michael Niedermayer authored 
      Requested-by: 's avatarPaul B Mahol <onemda@gmail.com>
This reverts commit caf7d617.
      c0702ab8
    • Rostislav Pehlivanov's avatar
      fate: add test for the Dirac low delay profile · 10b7adf7
      Rostislav Pehlivanov authored 
      Signed-off-by: 's avatarRostislav Pehlivanov <atomnuker@gmail.com>
      10b7adf7
    • James Almer's avatar
      x86/aacpsdsp: optimize ff_ps_mul_pair_single_sse · 933dd622
      James Almer authored 
      ~2% faster.
      933dd622
    • Sysiphus's avatar
      avformat/hls: Check local file extensions · caf7d617
      Sysiphus authored 
      This reduces the attack surface of local file-system
information leaking.

It prevents the existing exploit leading to an information leak. As
well as similar hypothetical attacks.

Leaks of information from files and symlinks ending in common multimedia extensions
are still possible. But files with sensitive information like private keys and passwords
generally do not use common multimedia filename extensions.
It does not stop leaks via remote addresses in the LAN.

The existing exploit depends on a specific decoder as well.
It does appear though that the exploit should be possible with any decoder.
The problem is that as long as sensitive information gets into the decoder,
the output of the decoder becomes sensitive as well.
The only obvious solution is to prevent access to sensitive information. Or to
disable hls or possibly some of its feature. More complex solutions like
checking the path to limit access to only subdirectories of the hls path may
work as an alternative. But such solutions are fragile and tricky to implement
portably and would not stop every possible attack nor would they work with all
valid hls files.

Developers have expressed their dislike / objected to disabling hls by default as well
as disabling hls with local files. There also where objections against restricting
remote url file extensions. This here is a less robust but also lower
inconvenience solution.
It can be applied stand alone or together with other solutions.
limiting the check to local files was suggested by nevcairiel

Found-by: Emil Lerner and Pavel Cheremushkin
Reported-by: 's avatarThierry Foucu <tfoucu@google.com>
Signed-off-by: 's avatarMichael Niedermayer <michael@niedermayer.cc>
      caf7d617
  3. 04 Jun, 2017 14 commits
  5. 03 Jun, 2017 6 commits
  7. 02 Jun, 2017 6 commits
  9. 01 Jun, 2017 4 commits
    • Kevin Mark's avatar
      libavfilter/scale2ref: Add constants for the primary input · 3385989b
      Kevin Mark authored 
      Variables pertaining to the main video are now available when
using the scale2ref filter. This allows, as an example, scaling a
video with another as a reference point while maintaining the
original aspect ratio of the primary/non-reference video.

Consider the following graph: scale2ref=iw/6:-1 [main][ref]
This will scale [main] to 1/6 the width of [ref] while maintaining
the aspect ratio. This works well when the AR of [ref] is equal to
the AR of [main] only. What the above filter really does is
maintain the AR of [ref] when scaling [main]. So in all non-same-AR
situations [main] will appear stretched or compressed to conform to
the same AR of the reference video. Without doing this calculation
externally there is no way to scale in reference to another input
while maintaining AR in libavfilter.

To make this possible, we introduce eight new constants to be used
in the w and h expressions only in the scale2ref filter:

 * main_w/main_h: width/height of the main input video
 * main_a: aspect ratio of the main input video
 * main_sar: sample aspect ratio of the main input video
 * main_dar: display aspect ratio of the main input video
 * main_hsub/main_vsub: horiz/vert chroma subsample vals of main
 * mdar: a shorthand alias of main_dar

Of course, not all of these constants are needed for maintaining the
AR, but adding additional constants in line of what is available for
in/out allows for other scaling possibilities I have not imagined.

So to now scale a video to 1/6 the size of another video using the
width and maintaining its own aspect ratio you can do this:

scale2ref=iw/6:ow/mdar [main][ref]

This is ideal for picture-in-picture configurations where you could
have a square or 4:3 video overlaid on a corner of a larger 16:9
feed all while keeping the scaled video in the corner at its correct
aspect ratio and always the same size relative to the larger video.

I've tried to re-use as much code as possible. I could not find a way
to avoid duplication of the var_names array. It must now be kept in
sync with the other (the normal one and the scale2ref one) for
everything to work which does not seem ideal. For every new variable
introduced/removed into/from the normal scale filter one must be
added/removed to/from the scale2ref version. Suggestions on how to
avoid var_names duplication are welcome.

var_values has been increased to always be large enough for the
additional scale2ref variables. I do not forsee this being a problem
as the names variable will always be the correct size. From my
understanding of av_expr_parse_and_eval it will stop processing
variables when it runs out of names even though there may be
additional (potentially uninitialized) entries in the values array.
The ideal solution here would be using a variable-length array but
that is unsupported in C90.

This patch does not remove any functionality and is strictly a
feature patch. There are no API changes. Behavior does not change for
any previously valid inputs.

The applicable documentation has also been updated.
Signed-off-by: 's avatarKevin Mark <kmark937@gmail.com>
Signed-off-by: 's avatarMichael Niedermayer <michael@niedermayer.cc>
      3385989b
    • Michael Niedermayer's avatar
      avcodec/asvdec: Use rounded up dimenensions in input size check · adb4854a
      Michael Niedermayer authored 
      Fixes: Timeout
Fixes: 2001/clusterfuzz-testcase-minimized-6187599389523968

Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpegSigned-off-by: 's avatarMichael Niedermayer <michael@niedermayer.cc>
      adb4854a
    • Michael Niedermayer's avatar
      avcodec/wavpack: Fix runtime error: shift exponent 32 is too large for 32-bit type 'int' · 8b3e580b
      Michael Niedermayer authored 
      Fixes: 1967/clusterfuzz-testcase-minimized-5757031199801344

Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpegSigned-off-by: 's avatarMichael Niedermayer <michael@niedermayer.cc>
      8b3e580b
    • Michael Niedermayer's avatar
      avcodec/cfhd: Fix runtime error: signed integer overflow: 65280 * 65288 cannot... · cd6f319a
      Michael Niedermayer authored 
      avcodec/cfhd: Fix runtime error: signed integer overflow: 65280 * 65288 cannot be represented in type 'int'

Fixes: 1925/clusterfuzz-testcase-minimized-5564569688735744

Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpegSigned-off-by: 's avatarMichael Niedermayer <michael@niedermayer.cc>
      cd6f319a