thorium
thorium copied to clipboard
Alex313031
[SECURITY] Missing all of the below CVE patches from the latest stable version 119.0.6045.105 and later
[$16000][1492698] High CVE-2023-5480: Inappropriate implementation in Payments. Reported by Vsevolod Kokorin (Slonser) of Solidlab on 2023-10-14
[$11000][1492381] High CVE-2023-5482: Insufficient data validation in USB. Reported by DarkNavy on 2023-10-13
[$TBD][1492384] High CVE-2023-5849: Integer overflow in USB. Reported by DarkNavy on 2023-10-13
[$3000][1281972] Medium CVE-2023-5850: Incorrect security UI in Downloads. Reported by Mohit Raj (shadow2639) on 2021-12-22
[$3000][1473957] Medium CVE-2023-5851: Inappropriate implementation in Downloads. Reported by Shaheen Fazim on 2023-08-18
[$2000][1480852] Medium CVE-2023-5852: Use after free in Printing. Reported by [pwn2car] on 2023-09-10
[$1000][1456876] Medium CVE-2023-5853: Incorrect security UI in Downloads. Reported by Hafiizh on 2023-06-22
[$1000][1488267] Medium CVE-2023-5854: Use after free in Profiles. Reported by Dohyun Lee (@l33d0hyun) of SSD-Disclosure Labs & DNSLab, Korea Univ on 2023-10-01
[$TBD][1492396] Medium CVE-2023-5855: Use after free in Reading Mode. Reported by ChaobinZhang on 2023-10-13
[$TBD][1493380] Medium CVE-2023-5856: Use after free in Side Panel. Reported by Weipeng Jiang (@Krace) of VRI on 2023-10-17
[N/A][1493435] Medium CVE-2023-5857: Inappropriate implementation in Downloads. Reported by Will Dormann on 2023-10-18
[$3000][1457704] Low CVE-2023-5858: Inappropriate implementation in WebApp Provider. Reported by Axel Chong on 2023-06-24
[$500][1482045] Low CVE-2023-5859: Incorrect security UI in Picture In Picture. Reported by Junsung Lee on 2023-09-13
The next one is version 118, which will contain all the patches that were merged into the 118 branch.
The next one is version 118, which will contain all the patches that were merged into the 118 branch.
The fact that the next major version is 118 isn't relevant here. What matters is that the latest stable is 119, and so 118 should be skipped to ensure Thorium users aren't vulnerable to the above exploits.
The next one is version 118, which will contain all the patches that were merged into the 118 branch.
The fact that the next major version is 118 isn't relevant here. What matters is that the latest stable is 119, and so 118 should be skipped to ensure Thorium users aren't vulnerable to the above exploits.
Agreed. 118 should be skipped for 119 since that's the latest stable Chromium release now 👍
Indeed, the update cadence of Thorium could be improved to be closer to upstream releases in general. This is primarily a security concern.
Yes, I do agree that the release cadence could be improved, but compiling a browser is a resource intensive endeavor and there is a cost associated with it on doing the CI/CD stuff, maybe we could have a campaign for a set number of patreon supporters or something with a 1-3 dollars subscription price to fund the cloud infrastructure to have automated releases which would greatly improve the contributors experience and enable a faster release schedule.
@gz83 @Alex313031 I understand that Alex is off github for [who knows how long], but the security vulnerabilities alone need to be addressed or this browser isn't safe to use on public networks.
Thorium macOS hasn't been updated since version M116.0.5845.169 on 2023-09-06, almost 100 days ago.
Since October 31, when this issue was opened, 31 new security fixes have been included in stable releases:
2023-11-07: 1 security fix was included in stable 119.0.6045.123 for Mac and Linux and 119.0.6045.123/.124 for Windows.
2023-11-14: 4 security fixes were included in stable 119.0.6045.159 for Mac and Linux and 119.0.6045.159/.160 for Windows.
2023-11-28: 7 security fixes were included in stable 119.0.6045.199 for Mac and Linux and 119.0.6045.199/.200 for Windows, including a zero day as of then.
2023-12-05: 10 security fixes were included in stable 120.0.6099.62 (Linux and Mac), 120.0.6099.62/.63( Windows).
2023-12-12: 9 security fixes were included in stable 120.0.6099.109 for Mac,Linux and Windows.
@earthsound While I agree with your sentiment and I agree that this browser is not safe to use, it is not as simple as patching "security vulnerabilities alone". Many security patches aren't backported to versions that are past extended stable.
This means that to stay on top of security patches, thorium needs to stay current with stable, which releases about twice a week on average.
In my opinion as an outsider to this project who has built it and tried to modify it a handful of times, staying on top of a twice a week upgrade schedule is simply not possible given current state of the codebase. Many of the patches aren't actually patch files, but entire .cc files that overwrite the original files. This means that if any of those files are changed upstream, major breakage can occur. I tried to upgrade thorium to 118 and 119 a month ago and ran into breakage because of this problem.
From my standpoint, all of the patches in thorium need a rewrite as patchfiles before we even discuss staying current with security updates. This would be a massive endeavour given the breadth of the changes. I suspect thorium started out as a personal project, so just overwriting upstream files entirely instead of using patch files was a quick and dirty way to achieve patching. Now however that this project has seen a huge visibility spike and increasing general usage, it simply isn't sustainable.
If I'm off base on any of these points, maintainers feel free to correct me.
@earthsound While I agree with your sentiment and I agree that this browser is not safe to use, it is not as simple as patching "security vulnerabilities alone". Many security patches aren't backported to versions that are past extended stable.
@qoijjj Perhaps I could've used better wording, but I never said it was as simple as patching vulnerabilities. I'm just pointing out that there are many security vulnerabilities that need to be addressed and you can't do that without new releases.
This means that to stay on top of security patches, thorium needs to stay current with stable, which releases about twice a week on average.
For stable Chrome, minor updates are every 2-3 weeks and major releases are every 4 weeks.
In my opinion as an outsider to this project who has built it and tried to modify it a handful of times, staying on top of a twice a week upgrade schedule is simply not possible given current state of the codebase. Many of the patches aren't actually patch files, but entire .cc files that overwrite the original files. This means that if any of those files are changed upstream, major breakage can occur. I tried to upgrade thorium to 118 and 119 a month ago and ran into breakage because of this problem.
I don't see any suggestions to release multiple times per week. However, once per month likely isn't asking too much.
@earthsound many of those minor updates are the ones with security patches. There are generally security patch releases twice a week for chromium. Doing a monthly major release would not solve this issue.
To your second point, it wouldn't be asking too much if the codebase was using patchfiles everywhere, but it isn't. It's just one person's opinion, but I don't see how a biweekly or even weekly cadence would be sustainable without doing a complete migration of thorium to use patchfiles, especially given that thorium has no CICD and everything is done manually by volunteers.
I don't see any suggestions to release multiple times per week.
You are. It's implicit in your suggestion to stay on top of security patches, since they are released around twice a week on average.
@earthsound many of those minor updates are the ones with security patches. There are generally security patch releases twice a week for chromium. Doing a monthly major release would not solve this issue.
@qoijjj Since you mentioned "stable version", I'm referring to stable Chrome releases (there are no "stable" chromium releases). Reviewing their releases over the past few years, the Chrome team moved to a two week refresh schedule for Chrome stable in 2020 but by 2021 they were releasing refreshes every 1-2 weeks. By 2022 they've released generally every week, though not all weekly refreshes have security fixes.
In 2023, Thorium has been generally been released once per month. While not idea, I prefer that to 3+ months.
To your second point, it wouldn't be asking too much if the codebase was using patchfiles everywhere, but it isn't. It's just one person's opinion, but I don't see how a biweekly or even weekly cadence would be sustainable without doing a complete migration of thorium to use patchfiles, especially given that thorium has no CICD and everything is done manually by volunteers.
Agreed.
I don't see any suggestions to release multiple times per week.
You are. It's implicit in your suggestion to stay on top of security patches, since they are released around twice a week on average.
I listed the dates/security fixes to show what's happened during the large gap since the last release and to encourage @gz83 to consider pushing releases while @Alex313031 is on hiatus for an indeterminate amount of time.
@earthsound
Reviewing their releases over the past few years, the Chrome team moved to a two week refresh schedule for Chrome stable in 2020 but by 2021 they were releasing refreshes every 1-2 weeks. By 2022 they've released generally every week, though not all weekly refreshes have security fixes.
"not all" is misleading. It's nearly every single week. All of the following releases had security patches and were released on the date listed:
120.0.6099.109 - 12/12/23 120.0.6099.62 - 12/05/23 119.0.6045.199 - 11/28/23 119.0.6045.159 - 11/14/23 119.0.6045.123 - 11/07/23 119.0.6045.105 - 10/31/23 118.0.5993.117 - 10/24/23 118.0.5993.88 - 10/17/23 118.0.5993.70 - 10/10/23 117.0.5938.149 - 10/03/23 117.0.5938.132 - 09/27/23
Agreed. to encourage @gz83 to consider pushing releases
You say you agree with my paragraph where I say that it's not sustainable to have a weekly cadence given the state of the codebase, but then also say you want to "encourage the maintainers to push releases". This is contradictory. If you genuinely agree that the codebase needs to be moved to patchfiles, your response wouldn't be thinking that we need to "encourage the maintainers".
What is needed is a number of volunteers to help migrate the codebase into a more sustainable and maintainable state based on patchfiles, and then have a few months long initiative to do that migration.
I've been using Thorium for the past couple of months and it would be a shame if it is discontinued.
Is the project currently looking for volunteers? What would be the requirements and expectations?
I've been using Thorium for the past couple of months and it would be a shame if it is discontinued.
Is the project currently looking for volunteers? What would be the requirements and expectations?
https://github.com/Alex313031/thorium/issues/464#issuecomment-1855133359
The Thorium project will still continue, it is not "dead"
@pnmcosta
@pnmcosta @qoijjj We are finally up to date with upstream. Gonna be releasing M120 soon (the code is ready, just have to build for all the platforms)
@Alex313031 That's great, but this is more of a systemic issue than something that gets fixed with one release. Do you have any strategies in mind for making weekly security patch releases a sustainable endeavour? A few that cross my mind would be:
- Switching to patchfiles wherever possible (like Vanadium does), to alleviate the need to ingest new versions of entire upstream files
- Automatically ingest and build new patch versions (in other words, if there's already a 120.X.X.X release, the next 120.X.X.X release should be automatically built and published when it's available)
Without these and/or other measures to make this project more maintainable, I don't think it'll be possible to keep it up to date with the latest patches (within 24-48 hours of upstream release), rendering it unusable for any users who care about security.
@pnmcosta @earthsound @Msouza91 @qoijjj @Void48 @ms178 M120 release is out for Linux and Windows now.
@Alex313031 as expected, it's already out of date and missing several CVE patches:
https://chromereleases.googleblog.com/2024/01/stable-channel-update-for-desktop_23.html
The Stable channel has been updated to 121.0.6167.85 for Mac and Linux
[$11000][[1505080](https://crbug.com/1505080)] High CVE-2024-0807: Use after free in WebAudio. Reported by Huang Xilin of Ant Group Light-Year Security Lab on 2023-11-25
[$9000][[1484394](https://crbug.com/1484394)] High CVE-2024-0812: Inappropriate implementation in Accessibility. Reported by Anonymous on 2023-09-19
[$6000][[1504936](https://crbug.com/1504936)] High CVE-2024-0808: Integer underflow in WebUI. Reported by Lyra Rebane (rebane2001) on 2023-11-24
[$2000][[1496250](https://crbug.com/1496250)] Medium CVE-2024-0810: Insufficient policy enforcement in DevTools. Reported by Shaheen Fazim on 2023-10-26
[$1000][[1463935](https://crbug.com/1463935)] Medium CVE-2024-0814: Incorrect security UI in Payments. Reported by Muneaki Nishimura (nishimunea) on 2023-07-11
[$1000][[1477151](https://crbug.com/1477151)] Medium CVE-2024-0813: Use after free in Reading Mode. Reported by @retsew0x01 on 2023-08-30
[$1000][[1505176](https://crbug.com/1505176)] Medium CVE-2024-0806: Use after free in Passwords. Reported by 18楼梦想改造家 on 2023-11-25
[TBD][[1514925](https://crbug.com/1514925)] Medium CVE-2024-0805: Inappropriate implementation in Downloads. Reported by Om Apip on 2024-01-01
[TBD][[1515137](https://crbug.com/1515137)] Medium CVE-2024-0804: Insufficient policy enforcement in iOS Security UI. Reported by Narendra Bhati of Suma Soft Pvt. Ltd. Pune (India) on 2024-01-03
[N/A][[1494490](https://crbug.com/1494490)] Low CVE-2024-0811: Inappropriate implementation in Extensions API. Reported by Jann Horn of Google Project Zero on 2023-10-21
[TBD][[1497985](https://crbug.com/1497985)] Low CVE-2024-0809: Inappropriate implementation in Autofill. Reported by Ahmed ElMasry on 2023-10-31
@Alex313031 as expected, it's already out of date and missing several CVE patches:
https://chromereleases.googleblog.com/2024/01/stable-channel-update-for-desktop_23.html
The Stable channel has been updated to 121.0.6167.85 for Mac and Linux[$11000][[1505080](https://crbug.com/1505080)] High CVE-2024-0807: Use after free in WebAudio. Reported by Huang Xilin of Ant Group Light-Year Security Lab on 2023-11-25 [$9000][[1484394](https://crbug.com/1484394)] High CVE-2024-0812: Inappropriate implementation in Accessibility. Reported by Anonymous on 2023-09-19 [$6000][[1504936](https://crbug.com/1504936)] High CVE-2024-0808: Integer underflow in WebUI. Reported by Lyra Rebane (rebane2001) on 2023-11-24 [$2000][[1496250](https://crbug.com/1496250)] Medium CVE-2024-0810: Insufficient policy enforcement in DevTools. Reported by Shaheen Fazim on 2023-10-26 [$1000][[1463935](https://crbug.com/1463935)] Medium CVE-2024-0814: Incorrect security UI in Payments. Reported by Muneaki Nishimura (nishimunea) on 2023-07-11 [$1000][[1477151](https://crbug.com/1477151)] Medium CVE-2024-0813: Use after free in Reading Mode. Reported by @retsew0x01 on 2023-08-30 [$1000][[1505176](https://crbug.com/1505176)] Medium CVE-2024-0806: Use after free in Passwords. Reported by 18楼梦想改造家 on 2023-11-25 [TBD][[1514925](https://crbug.com/1514925)] Medium CVE-2024-0805: Inappropriate implementation in Downloads. Reported by Om Apip on 2024-01-01 [TBD][[1515137](https://crbug.com/1515137)] Medium CVE-2024-0804: Insufficient policy enforcement in iOS Security UI. Reported by Narendra Bhati of Suma Soft Pvt. Ltd. Pune (India) on 2024-01-03 [N/A][[1494490](https://crbug.com/1494490)] Low CVE-2024-0811: Inappropriate implementation in Extensions API. Reported by Jann Horn of Google Project Zero on 2023-10-21 [TBD][[1497985](https://crbug.com/1497985)] Low CVE-2024-0809: Inappropriate implementation in Autofill. Reported by Ahmed ElMasry on 2023-10-31
Please do not frequently urge the release of new versions. Alex and I both know the importance of timely updating of security patches for browser security, but currently we cannot follow up on every patch in a timely manner (we do not have a huge maintenance system like Google) ), please understand.
Please do not frequently urge the release of new versions. Alex and I both know the importance of timely updating of security patches for browser security, but currently we cannot follow up on every patch in a timely manner (we do not have a huge maintenance system like Google) ), please understand.
I understand, but you misunderstand me somewhat. My goal isn't to urge the release of a new version. I understand that as-is, this is not feasible. My goal in this issue is to highlight that systemic and infrastructural change is needed for this project to enable it to be feasible.
we do not have a huge maintenance system like Google
There are ways to set up the infrastructure that would be needed. COPR comes to mind. PPAs come to mind. For Windows builds, Azure's free CI/CD comes to mind. Fedora's chromium rpm as an example is maintained largely by a single volunteer, has dozens of patches applied, and automatically builds new versions.
The point being, this isn't the intractable problem you're making it out to be.
@qoijjj @gz83 It's not about building, so COPR and PPA wouldn't help. It's about rebasing. Some stuff could be rebased with patch files, but most of thorium has to be painstakingly manually rebased by me, one file at a time. Plus maintaining the other builds for other platforms, and my other projects.
And although this does sometimes put Thorium behind on security updates, keep in mind that: I always use the latest minor patch version of a milestone, which often backports security patches from the next milestone. And that just because you are one version behind doesn't mean the browser automatically becomes a magnet for viruses. Unless it's a zero day + you are personally targeted. Case in point, I used Chromium M49 on Windows XP without an anti-virus until 2019. I now use Thorium M109 on Windows 7 without an anti-virus. In both instances I used it daily for hours. I never do banking or stuff like that on these OSes, but I never had any problems or infections. And no there weren't any hidden non-obvious infections either, as I would run Kapersky, MSE, and another one i forgot the name of every month just to scan and be sure.
It's not about building, so COPR and PPA wouldn't help. It's about rebasing. Some stuff could be rebased with patch files, but most of thorium has to be painstakingly manually rebased by me, one file at a time. Plus maintaining the other builds for other platforms, and my other projects.
Yeah, you hit the nail on the head here. The reason packages like fedora's chromium can be maintained by a single maintainer is that all of their changes are in patchfiles. This makes rebasing minimal. It would be a collosal upfront effort to move everything to patchfiles, but would save tenfold the effort in the longrun.
If you decide to do this move to patchfiles and need volunteers, count me in. Although if we'd be going with a divide-and-conquer approach, we'd probably want a dozen or so.