Recherche avancée

Sur d’autres sites (12325)

• releases doc formating

  13 février 2013, par jonrohan

  m docs/releases.md
  

  releases doc formating

• fftools/ffmpeg : replace MATCH_PER_STREAM_OPT(.., str, ..) with a function

  6 août 2024, par Anton Khirnov

  fftools/ffmpeg : replace MATCH_PER_STREAM_OPT(.., str, ..) with a function
  This has multiple advantages :
  
  * The macro has multiple parameters that often have similar or identical
  
    values, yet very different meanings (one is the name of the
  
    OptionsContext member where the parsed options are stored, the other
  
    the name of the variable into which the result is written) ; this
  
    change makes each of these explicit.
  * The macro returns on failure, which may cause leaks - this was the
  
    reason for adding MATCH_PER_STREAM_OPT_CLEAN(), also ost_add()
  
    currently leaks encoder_opts. The new function returns failure to its
  
    caller, which decides how to deal with it. While that adds a lot of
  
    error checks/forwards for now, those will be reduced in following
  
    commits.
  * new code is type- and const- correct
  Invocations of MATCH_PER_STREAM_OPT() with other types will be converted
  
  in following commits.
  

  • [DH] fftools/cmdutils.c
  • [DH] fftools/cmdutils.h
  • [DH] fftools/ffmpeg.h
  • [DH] fftools/ffmpeg_demux.c
  • [DH] fftools/ffmpeg_mux.h
  • [DH] fftools/ffmpeg_mux_init.c
  • [DH] fftools/ffmpeg_opt.c

• avformat/hls : Check local file extensions

  3 juin 2017, par Michael Niedermayer

  avformat/hls : Check local file extensions
  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 : Thierry Foucu <tfoucu@google.com>
  Signed-off-by : Michael Niedermayer <michael@niedermayer.cc>
  

  • [DH] libavformat/hls.c