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/1783317
Title:
[MIR] sshfs-fuse
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/sshfs-fuse/+bug/1783317/+subscriptions
--
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
