File: SECURITY

package info (click to toggle)
libabigail 2.9-2
  • links: PTS
  • area: main
  • in suites: forky, sid
  • size: 1,021,756 kB
  • sloc: xml: 572,663; cpp: 110,945; sh: 11,868; ansic: 4,329; makefile: 3,486; python: 1,684; ada: 62
file content (34 lines) | stat: -rw-r--r-- 1,574 bytes parent folder | download
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
The libabigail library and utilities aim to be generally robust and
reliable.  However, libabigail routinely processes complex binary
structured data.  This makes the code intricate and sometimes brittle.
While libabigail developers use a variety of static and dynamic checker
software (valgrind, sanitizers) in testing, bugs may remain.  Some of
these bugs may have security-related implications.


While many errors are cleanly detected at runtime, it is possible that
vulnerabilities exist that could be exploitable.  These may arise from
crafted / fuzzed / erroneous inputs, or perhaps even from valid inputs
with unforseen characteristics.  Therefore, to minimize risks, users
of libabigail tools and libraries should consider measures such as:

- avoiding running complex libabigail analysis on untrustworthy inputs
- avoiding running libabigail tools as privileged processes
- applying common platform level protection mechanisms such as
  selinux, syscall filtering, hardened compilation, etc.

Since libabigail tools are usually run in short-lived, local,
interactive, development context rather than remotely "in production",
we generally treat malfunctions as ordinary bugs rather than security
vulnerabilities.

Please report bugs via any of:
- email to <libabigail@sourceware.org>
- https://sourceware.org/bugzilla/enter_bug.cgi?product=libabigail

After considering the above exclusions, please report suspected
security vulnerabilities confidentially via any of:

- email to <dodji@seketeli.org>
- email to <fche@elastic.org>
- email to <secalert@redhat.com>