Recherche avancée

Sur d’autres sites (9793)

• avformat/hls : Check local file extensions

  3 juin 2017, par Sysiphus

  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
  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

• Merge commit 'b9129ec4668c511e0a79e25c6f25d748cee172c9'

  10 novembre 2017, par James Almer

  Merge commit 'b9129ec4668c511e0a79e25c6f25d748cee172c9'
  * commit 'b9129ec4668c511e0a79e25c6f25d748cee172c9' :
  
    h264dec : add a CUVID hwaccel
  
    decode : add a per-frame private data for hwaccel use
  
    decode : add a mechanism for performing delayed processing on the decoded frames
  
    decode : add a method for attaching lavc-internal data to frames
  
    decode : avoid leaks on failure in ff_get_buffer()
  This commit is a noop, see
  
  4776c61424fa32394e251e9769e1ad2c2fa55598
  
  9f1cfd88af88a7d7d5c56a368a46639dfdfdef75
  
  7fa64514c8d2ec4d3dcb5f194511609ddcc288e6
  
  81c021c6a2d7848c31984d65f225ba54bdd6f560
  
  0e00624389955bc559d75855d5c4876266d9575f
  Merged-by : James Almer <jamrial@gmail.com>
  

• avformat/segment : Fix leak and invalid free of AVIOContext

  6 septembre 2020, par Andreas Rheinhardt

  avformat/segment : Fix leak and invalid free of AVIOContext
  seg_init() and seg_write_header() currently contain a few error paths
  
  in which an already opened AVIOContext for the child muxer leaks (namely
  
  if there are unrecognized options for the child muxer or if writing the
  
  header of the child muxer fails) ; the reason for this is that this
  
  AVIOContext is not closed in the deinit function. If all goes well, it
  
  is closed when writing the trailer. From this it also follows that the
  
  AVIOContext also leaks when the trailer is never written, even when
  
  writing the header succeeds.
  But simply freeing said AVIOContext in the deinit function is
  
  complicated by the fact that the AVIOContext may or may not have been
  
  opened via the io_open callback : If options are set to discard header
  
  and trailer, said AVIOContext can also be a null context which must not
  
  be closed via the io_close callback. This may lead to crashes, as
  
  io_close may presume the AVIOContext's opaque to be set. It currently
  
  works with the default io_close callback which simply calls avio_close(),
  
  because avio_close() doesn't care about opaque being NULL since commit
  
  6e8e8431e15a58aa44cfdd8c11f9ea096837c0fa. Therefore this commit records
  
  which of the two kinds of AVIOContext is currently in use to use the
  
  right way to close it.
  Finally there was one instance (namely if initializing the child muxer
  
  fails with no unrecognized options) where the AVIOContext was always
  
  closed via the io_close callback. The above remark applies to this ; it
  
  has been fixed, too.
  Reviewed-by : Ridley Combs <rcombs@rcombs.me>
  
  Signed-off-by : Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
  

  • [DH] libavformat/segment.c