Check_password not called if OTP is enabled - update ASAP if you're using 2FA

Tiny Tiny RSS Support
1

Using v21.03-a4da2f1e6 updated via git

Problem

When checking in database if my users have updated their hashed passwords, I saw that mine is not updated. So, I tried to log-out and -in, and me password is not updated with the new hash algo.
But, in the code, I saw that the password is forced to be updated in the check_password function, so I tried to login again, with a bad password but a correct OTP, and it was successful.

I do not know if this is a bug, or (weirdly?) if a correct OTP is considered sufficient to login to TT-RSS.

Reproducing the problem:

  1. Enable OTP for a user
  2. Logout
  3. Login with the user and a bad password
  4. Enter a correct OTP
2

yep. my bad. everyone should probably update right now.

https://git.tt-rss.org/fox/tt-rss/commit/4949e1a59059d9e72ba7a98f783cec312c06c6d2

blunder of the century, etc, etc. :cry:

btw, this is the kind of stuff best reported in private. imagine if it was something easier exploitable, your public report gave everyone 7 hours to play around with it (and more, until people update).

4

Thank you @GregThib for finding this and @fox for fixing it so quickly!

5

Oh yes, you are right.

6

Someone should probably request a CVE for this

7

i’m not gonna bother but here’s the timeline

4949e1a590 plugins/auth_internal/init.php (Andrew Dolgov 2021-03-12 07:32:15 +0300  53)                                         if ($this->check_password($user_id, $password) && UserHelper::check_otp($user_id, $otp))
3fd7856543 plugins/auth_internal/init.php (Andrew Dolgov 2021-02-26 19:16:17 +0300  54)
        return $user_id;

fixed, introduced

8

Okay, I will do this

9

Submitted. I’ll update here when I receive the CVE ID

10

Thanks everyone for your work. I have always wondered though why fox and others put so much work into security for TT-RSS. What are people using TT-RSS for that warrants so much security, like getting a CVE for this, using OTP for logins, and the csrf protections?

I use TT-RSS to read news, changelogs, comics, announcements, etc. I want it to be secure so hackers don’t mess up my settings and mark things as read before I read them, but those would just be annoyances that I’d fix using web server level password protection.

I wish other OSS projects would put this level of effort into their programs’ security.

11

tbh i’m largely in the same boat.

i wouldn’t bother with a cve (i have no idea where one would get it anyway), i don’t use otp for tt-rss because who cares, the only thing that’s really unavoidable is csrf, if there’s any internet content involved.

yeah this is pretty much the extent of horrific exploits possible via properly containerized tt-rss.

12

Why is everyone understating the value of daily comics? :smirk:

I don’t even use passwords… I just use certificates to authenticate. It’s annoying to setup, but it’s a one time thing and then I never have to “login” to TT-RSS, I just visit the web site and read.

13

this guy gets it. i could get by with md5 unsalted passwords but i can’t survive without af_comics.

e: its a shame after tumblr died many people moved to instagram which is apparently pretty much impossible to scrape. tumblr had rss feeds. good times.

14

Hey! I’m a security researcher, so I am a bit biased, but here’s my take on it:

Good security is done in layers (see swiss cheese model). An extreme example would be someone compromising the TT-RSS instance, gaining RCE (Remote Code Execution), and using a Docker escape exploit to breach the entire server running the Docker daemon.

Assuming the Docker installation is safe, there are still risks in compromising the TT-RSS instance, as shown in our previous research where we could gain RCE. We were able to use a combination of relatively low-impact bugs to compromise the entire installation. In this example, an attacker with access to a popular RSS feed could run arbitrary code on all TT-RSS clients subscribed to this feed, thus making it possible to build a botnet for other nefarious purposes. I encourage you to read the report if you want to know more about it.

Coming back to the current vulnerability, the impact is obviously low. But requesting a CVE still has positive value for internet security. Whether fox likes it or not, many Linux distributions package their own TT-RSS, which is rarely updated. I saw some developers fixed the issues we discovered few months after we made the report public, and that was for an RCE. By issuing a public CVE identifier, we make them aware of existing security issues, increasing the chance they’ll update.

15

CVE-2021-28373 is assigned to this issue.