> We need a fix for the critical SQLLite vulnerability:
> https://thehackernews.com/2018/12/sq...erability.html
Yep, I have seen this. No reason to panic, though. First of all we'll
have to wait for DBD::SQLite to be updated
(https://metacpan.org/changes/distribution/DBD-SQLite) any way.
Secondly: this vulnerability does require specially prepared content to
reach your .db file. According to the reporters this requires either
somebody able to execute SQL commands on the database. Or you open a
prepared .db file you received from the attacker. Or as the reporters
describe it:
"(4) What are the conditions for exploiting the vulnerability?
This vulnerability can be triggered remotely, such as accessing a
particular web page in a browser,Or any scenario that can execute SQL
statements."
I see two potential ways how this could be exploited in LMS:
- you scan a prepared music file which comes with the critical
instructions as part of its metadata
- you use a plugin which requests external data and stores the raw data
in the LMS cache
The first one is easy to prevent: don't download music files from
dubious sources ;-).
The second one probably is not critical either (will have to verify the
code): imagine eg. a prepared podcast stream file. That's XML, text. We
would indeed store it in cache.db. Alas, we never store the raw text
data, but add some metadata and serialize it into a binary before
storing it in the database. I'm pretty sure manipulated content will be
mangled enough to be safe to be stored.
One more thing: from what I understand the underlying flaw is in the
"shadow tables", used by eg. the full text search. Disabling the FTS
plugin in LMS might further reduce the attack surface of your LMS.
All that said I'll have to verify my assumptions and will see what we
can do about updating the binaries we're using.
--
Michael
> https://thehackernews.com/2018/12/sq...erability.html
Yep, I have seen this. No reason to panic, though. First of all we'll
have to wait for DBD::SQLite to be updated
(https://metacpan.org/changes/distribution/DBD-SQLite) any way.
Secondly: this vulnerability does require specially prepared content to
reach your .db file. According to the reporters this requires either
somebody able to execute SQL commands on the database. Or you open a
prepared .db file you received from the attacker. Or as the reporters
describe it:
"(4) What are the conditions for exploiting the vulnerability?
This vulnerability can be triggered remotely, such as accessing a
particular web page in a browser,Or any scenario that can execute SQL
statements."
I see two potential ways how this could be exploited in LMS:
- you scan a prepared music file which comes with the critical
instructions as part of its metadata
- you use a plugin which requests external data and stores the raw data
in the LMS cache
The first one is easy to prevent: don't download music files from
dubious sources ;-).
The second one probably is not critical either (will have to verify the
code): imagine eg. a prepared podcast stream file. That's XML, text. We
would indeed store it in cache.db. Alas, we never store the raw text
data, but add some metadata and serialize it into a binary before
storing it in the database. I'm pretty sure manipulated content will be
mangled enough to be safe to be stored.
One more thing: from what I understand the underlying flaw is in the
"shadow tables", used by eg. the full text search. Disabling the FTS
plugin in LMS might further reduce the attack surface of your LMS.
All that said I'll have to verify my assumptions and will see what we
can do about updating the binaries we're using.
--
Michael