I reviewed robot-detection version 0.4.0-1 as checked into disco. This
should not be considered a full security audit, but rather a quick gauge
of maintainability.
- There are no prior CVEs against robot-detection
- Build depends:
debhelper (>= 9),
dh-python,
python-all,
python-setuptools,
python-six,
python3-all,
python3-setuptools,
python3-s
- does not daemonize
- no initscripts
- no dbus services
- no setuid files
- no sudo fragments
- no udev rules
- does not fork
- Test suite performs some simple "feel-good" tests but does not test
for error cases. These tests are run during build.
- no cronjobs
- no logging (not applicable)
- This project has had no activity in the past 2.5 years.
- does not use WebKit
- does not use PolicyKit
- does not use Javascript
- no memory management concerns
The meat of this package is a single 10 line function that compares a
string to a predefined set of user agent strings (stored as regexes).
While this is very simple, I have two main concerns about this package:
1) The mechanism for updating the set of known user agent strings is
to modify the source code. I would like to see a less error-prone
mechanism for updating the user agent definitions, such as a
configuration file. This could require a significant change in
the way this library is used. This concern is more about quality
and supportability than security.
2) The is_robot() function can raise a TypeError or ValueError, but
provides no documentation that informs the user of this behavior.
The user would have to audit the code themselves to become aware
of the possible exceptions. If a user is unaware that exceptions
may be raised, the unchecked use of is_robot() may lead to a
crashed application. A pull request has been submitted upstream
to update the README.md.
https://github.com/rory/robot-detection/pull/1
As used in hyperkitty, I have concerns that is_robot() could potentially
raise a TypeError, causing hyperkitty to crash.
https://sources.debian.org/src/hyperkitty/1.2.2-1/hyperkitty/views/thread.py/?hl=154#L154
This risk may be mitigated by 2 factors: Based on a cursory audit of
django, I could not find any condition where the user agent would be
returned as anything other than a string. Secondly, it's possible that
the django framework would catch any exceptions raised by hyperkitty's
thread_index() function.
As I only briefly investigated these mitigations, a further
investigation is recommended during the MIR for hyperkitty. Caveats
against either of these mitigations could potentially make hyperkitty's
use of is_robot() result in a DoS. Regardless of these mitigations,
hyperkitty's reliance on django to catch or avoid exceptions in
robot_detection is fragile and ill-advised.
Since I did not find any security concerns in robot-detection itself,
ACK from the security team for promoting to main.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1820225
Title:
[MIR] robot-detection as dependency of mailman3
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/robot-detection/+bug/1820225/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
