I reviewed fence-agents 4.7.1-1ubuntu6 as checked into impish. This shouldn't
be
considered a full audit but rather a quick gauge of maintainability.
fence-agents provides per-hardware or cloud details on how to forcibly
remove a machine from a high-availability setup, whether it's by yanking
power or by yanking network. It's nothing but sharp edges and corner
cases.
- CVE History:
- two cves: one not validating tls certificates, one a non-ascii error
causing a failure to fence
- Build-Depends: autoconf,
automake,
debhelper-compat (= 13),
dh-python,
iputils-ping,
libglib2.0-dev,
libnspr4-dev,
libnss3-dev,
libtool,
perl,
python3,
python3-boto3,
python3-googleapi,
python3-oauth2client,
python3-pexpect,
python3-pycurl,
python3-requests,
python3-suds,
time,
xsltproc,
libxml2-utils,
libnet-telnet-perl
- pre/post inst/rm scripts?
- Automatically-added dh_python3
- init scripts?
- none
- systemd units?
- none
- dbus services?
- none
- setuid binaries?
- none
- binaries in PATH?
- many, all start /usr/sbin/fence_
- sudo fragments?
- none
- polkit files?
- none
- udev rules?
- none
- unit tests / autopkgtests?
- I didn't spot any unit tests
- autopkgtests provide a simple smoke test, better than nothing
- cron jobs?
- none
- Build logs:
- nothing too drastic, but they do give the impression they are unread
- lintian unhappy:
E: fence-agents-common: dir-or-file-in-var-run var/run/cluster/
- Processes spawned?
- that's the whole point of the project; the commands shut machines off,
so pretty much only handling trusted inputs, so I didn't inspect calls
carefully
- Memory management?
- Python
- File IO?
- under control of callers
- Logging?
- extensive -- sometimes logs passwords. I opened an issue for this.
- Environment variable usage?
- Nothing explicit
- Use of privileged functions?
- extensive, the point of the project
- Use of cryptography / random number sources etc?
- it's very easy to bypass certificate requirements
- Use of temp files?
- two fixed path names in /tmp, one in 'dummy' the other in 'rhevm'.
Probably not in the threat model of the project.
- Use of networking?
- extensive, the point of the thing; nothing stood out as drastically
unsafe but it does feel like it assumes everything is trusted
- Use of WebKit?
- none
- Use of PolicyKit?
- none
- Any significant cppcheck results?
- none
- Any significant Coverity results?
- not really, some dead code due to bug, I opened an issue
- Any significant shellcheck results?
- not really
- Any significant bandit results?
- points out some exec(), system(), subprocess(), assert(), and
something about unsafely handling xml. Nothing sounds like a surprise.
fence-agents sits in an interesting space with lots of networking and
highly privileged operations, command executions, etc, as the main goal.
It's probably best to assume inputs are pretty well trusted.
It looked professionally programmed, but by its nature it just does unsafe
operations.
I think we need to fix the lintian error:
E: fence-agents-common: dir-or-file-in-var-run var/run/cluster/
before we promote this to main -- I expect this will cause dpkg
unhappyness after a reboot, if not outright incorrect operation of the
tools.
Security team ACK for promoting fence-agents to main.
Here's some notes I took while reading it. I filed two issues for things,
but neither looks like a big deal to me.
set_boot_order() in agents/amt_ws/fence_amt_ws.py misunderstands python 'or'
https://github.com/ClusterLabs/fence-agents/issues/434
fence-agents/agents/eps/fence_eps.py can debug-log passwords
https://github.com/ClusterLabs/fence-agents/issues/436
fence_action() in agents/autodetect/fencing.py uses status.upper() when
status might be None
get_instance_id() in agents/aws/fence_aws.py is claimed to pass data
retrieved from the metadata service in a header to the metadata service --
I'm not convinced, but it'd be nice if someone gives this a look.
fence_action() in lib/fencing.py.py uses status.upper() when
status might be None
** Changed in: fence-agents (Ubuntu)
Assignee: Ubuntu Security Team (ubuntu-security) => (unassigned)
** Bug watch added: github.com/ClusterLabs/fence-agents/issues #434
https://github.com/ClusterLabs/fence-agents/issues/434
** Bug watch added: github.com/ClusterLabs/fence-agents/issues #436
https://github.com/ClusterLabs/fence-agents/issues/436
** Changed in: fence-agents (Ubuntu)
Status: Confirmed => In Progress
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1927004
Title:
[MIR] fence-agents
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/fence-agents/+bug/1927004/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
