Posts by grapheneos@infosec.exchange
(DIR) Post #APfwlVFCyGvDG7uHsu by grapheneos@infosec.exchange
2022-11-16T19:50:45Z
0 likes, 0 repeats
@fox @sirdarckcat We increasingly lack an incentive to file issues upstream. Consider if for the lockscreen bypass we had shipped a fix right away in June and then published information on it in August including instructions on how anyone could have exploited it. This would have helped to promote GrapheneOS and gotten us a lot more than $70k of value. Perhaps we're going to start taking that approach even with remote code execution bugs. We can pay someone to help us develop a proof of concept exploit and use it to raise awareness about our project, because reporting it upstream is clearly a waste. Maybe they'll even fix issues much faster if we take that approach instead.
(DIR) Post #APfwlgKvjL2Df3fVpY by grapheneos@infosec.exchange
2022-11-16T22:44:47Z
0 likes, 1 repeats
@sirdarckcat @fox That's a complete misrepresentation of what we said. You don't seem to understand that GrapheneOS is a non-profit open source project and nothing we do is for profit unlike everything you do at work being for Google to profit.Looking out for our own users is very arguably the most ethical approach and that means fixing issues as soon as possible, shipping the fixes, disclosing that we fixed an issue in our release notes as part of documenting our changes and then following it up with a proof of concept / post about it later to benefit all GrapheneOS users.Google's security bulletin system exists for marketing. The vulnerabilities are broadly disclosed to thousands of different companies and organizations 30 days in advance as if that's not giving it to every attacker capable of writing a sophisticated exploit chain who wants to get their hands on it.Shipping fixes for GrapheneOS, waiting a couple months and then getting credit for doing it is what would benefit us the most. Why should we keep doing free / poorly compensated work for a massive corporation that's substantially harming us? Google is looking out for themselves and we can't keep doing charity work for you, sorry.Some of our users are upset with us waiting months for Google when we had a fix available in June and we aren't going to do that again after this experience. Is holding back GrapheneOS security because of Google's slowness ethical? Why? And why shouldn't we get the most benefit we can for our project by waiting a couple weeks or even months and then publicizing it? If anything that will incentivize Google to fix these bugs in a reasonable time like 14 days instead of 150 days.
(DIR) Post #APfxSlZq7d1SMmBdOi by grapheneos@infosec.exchange
2022-11-16T22:54:08Z
1 likes, 1 repeats
@sirdarckcat @fox GrapheneOS is meant to be protecting GrapheneOS users first, not everyone else first with GrapheneOS users getting deprioritized. Does it really make sense for us to have to leave GrapheneOS users vulnerable for 150 days to wait for Google? No.
(DIR) Post #APfxf9XaqpYeAD2gWO by grapheneos@infosec.exchange
2022-11-16T22:56:29Z
3 likes, 1 repeats
@inference @fox Google discloses the patches 30 days early to every Android partner and they aren't allowed to fix them until the embargo expires on the first Monday of the next month. The patches are WIDELY distributed for 30 days in advance. They aren't even pretending that the system is viable. We could start getting someone at an Android partner to leak us the patches to start fixing half the issues a whole month early. Perhaps we will. If they don't like that they can stop broadly leaking them early.
(DIR) Post #APfyeP0Fydb3meegr2 by grapheneos@infosec.exchange
2022-11-16T22:53:07Z
0 likes, 0 repeats
@fox What's the point of disclosing vulnerabilities to literally hundreds of different companies / organizations including many known to leak them early and then waiting 30 days pretending that they're still private? That's the Android security bulletin system. As a bonus, many of the security patches are only recommended, not mandatory, and are listed separately in Pixel security bulletins. This has more to do with difficulty of fixing than severity. Each month also splits the patch level into YYYY-MM-01 and YYYY-MM-05 so that companies can claim to have the latest month's patch while having half of the current month's patches missing until next month.It genuinely comes across as a marketing-first system.
(DIR) Post #APfyeQ249OdcyYVeJU by grapheneos@infosec.exchange
2022-11-16T23:05:30Z
1 likes, 1 repeats
@sirdarckcat @fox GrapheenOS is a vendor and we are primarily responsible for protecting our users, not other users. Google doesn't disclose vulnerabilities to us early and doesn't give us information. For some reason you expect us to give you information early or at all when you do neither with us. You think it would be wrong for us to disclose without reporting issues to you but you do that every month in relation to us.
(DIR) Post #APfyeQXcG5sKYPGqUS by grapheneos@infosec.exchange
2022-11-16T22:59:33Z
0 likes, 0 repeats
@fox Not to mention that the time from an issue report until disclosure tends to be around 120 to 150 days. They're usually unable to meet the incredibly generous 90 day disclosure deadlines set by their own Project Zero, and for something even non-technical people can easily discover like that lockscreen bypass even 90 days is a bit ridiculous.After this issue was made public, it became apparent several Android vendors were aware of the issue years earlier and had fixed it themselves without reporting it. The status quo is ridiculous. We aren't interested in participating in it anymore.
(DIR) Post #APfyhtJBl75GdvArLs by grapheneos@infosec.exchange
2022-11-16T23:07:30Z
1 likes, 1 repeats
@fox We've already been doing that for a while. Due to an oversight we didn't patch this lockscreen bypass as soon as it was closed as a duplicate which has been our existing approach. That was a mistake due to being busy with so many other things and not properly keeping track of this. Some of our users are upset we didn't fix this issue in June/July, and we understand why.
(DIR) Post #APfyuhCa59ZyrMBnHs by grapheneos@infosec.exchange
2022-11-16T23:10:17Z
1 likes, 1 repeats
@fox @sirdarckcat Google doesn't keep disclosed vulnerabilities private. They essentially leak it 30 days in an advance every month.They 'accidentally' leaked a bunch of the December 2022 security patch through their QPR1 Beta releases, since QPR1 is coming out in December and they are testing the code that's going to ship. This is the norm, and we usually pick up those patches early from QPR releases. Look at the older branches of the GrapheneOS kernels and you'll see they're on the December 2022 security patch already. Our kernels for the newer devices are far ahead of that since we use the LTS GKI branches... more like what will ship in April 2023.
(DIR) Post #APfzPCxmYhw23Logtc by grapheneos@infosec.exchange
2022-11-16T23:15:11Z
1 likes, 1 repeats
@fox @sirdarckcat Leaking December patches in the QPR1 Beta is not protecting their users.December security patch is not available to Pixel users unless they use the QPR1 Beta which has a lot of it. Very few users are going to use those Betas and they have caveats.They're breaking their own embargo as they do with every QPR release. They break their own embargo every month by broadly disclosing the patches to a thousand companies 30 days in advance. There is no serious embargo / coordinated disclosure in this ecosystem.We have the right to fix our code and protect our users whenever we want to, and we'll be doing it going forward instead of working with them.
(DIR) Post #APfzVYyncCrA4bK4BM by grapheneos@infosec.exchange
2022-11-16T23:16:32Z
1 likes, 1 repeats
@fox @sirdarckcat You seem to be seriously misunderstanding something. GrapheneOS is not behind the stock Pixel OS on security updates. We're ahead of them on security updates because we ship the patches they leak early along with other upstream patches early. We're partly shipping the December security patch already, they are not. The 30 day early disclosure is to provide 30 days for vendors to get ready to patch issues. They are not allowed to ship the fixes early...
(DIR) Post #APfzt6gsRe1jHoAMwi by grapheneos@infosec.exchange
2022-11-16T23:21:06Z
1 likes, 1 repeats
@fox @sirdarckcat If we agreed to Google's terms to receiving the patches 30 days early, we'd have to agree not to ship them early. They don't ship the patches until the embargo ends, and other vendors agree not to ship them early. Those other vendors often break the embargo by 'accident' and Google does the same with their Beta releases. Google doesn't ship the patches to end users before they're disclosed publicly and pushed to AOSP. Google ships them early only in Beta releases, leaking fixed vulnerabilities before patches are available to 99.9% of their users. It is not us being irresponsible here.
(DIR) Post #APg0mQg5plRhCeBAvY by grapheneos@infosec.exchange
2022-11-16T23:24:03Z
1 likes, 1 repeats
@fox @sirdarckcat Google discloses the monthly security patches very broadly to hundreds of Android partners 30 days in advance, and we're capable of getting access to them consistently. The main issue is that we'd have to carefully review them and make sure the patches are valid in order to apply them. We don't have the resources to handle this right now but we could be doing it in theory.
(DIR) Post #APg0mSGzu2Ym9OSA5Y by grapheneos@infosec.exchange
2022-11-16T23:25:55Z
0 likes, 0 repeats
@fox @sirdarckcat Google has leaked at least half of the December 2022 patches in their QPR (quarterly release also known as a Pixel feature drop) Beta releases. There aren't source code tags publishing for more than the kernels but it would be possible to reverse engineer the patches. They regularly do this with quarterly and yearly release Betas. They are leaking patches as a matter of their regular procedures. No one who cares a lot about an embargo would be okay with Google broadly disclosing a vulnerability to hundreds of companies 30 days in advance which then disclose them to a bunch of additional companies/contractors.
(DIR) Post #APipNvC8igUUaX9y1A by grapheneos@infosec.exchange
2022-11-18T01:13:38Z
0 likes, 0 repeats
There have been major federation issues on Matrix with matrix.org today and many users in #grapheneos:grapheneos.org were dropped from the room and unable to rejoin. We think we've fixed the joining issue by setting it to invite-only and back to public.We aren't able to dedicate resources to identifying what went wrong with the Matrix protocol/federation. This could be a serious Matrix state reset bug. We'd appreciate help with figuring out the member list before it occurred so that we can reinvite 1.5k people who were dropped.We've filed an issue about this at https://github.com/matrix-org/synapse/issues/14481.We used to regularly experience these serious state reset / corruption issues with our previous rooms. We haven't experienced it since we created new Matrix rooms after the freenode takeover to replace our IRC channels.If you're having trouble (re)joining our main Matrix room, please let us know. Consider joining our discussion forum at https://discuss.grapheneos.org in the meantime. Matrix room tends to be nicer for getting quick support and short form answers but our forum is often a better fit now.#grapheneos #matrix #matrixchat #matrixdotorg
(DIR) Post #APjnMPNtV0IAtFli9A by grapheneos@infosec.exchange
2022-11-18T19:20:10Z
2 likes, 2 repeats
GmsCompatConfig version 16 is now in the stable channel of our app repository. It resolves the Play Store trying to update itself and Play services to unsupported versions. It's now back to requesting user install an update which only adds split packages.https://github.com/GrapheneOS/platform_packages_apps_GmsCompat/commit/70f6239af73062d7849a641de7ac8a9a4455f06bWe're not planning on addressing this for the legacy 3rd generation Pixels which are completely insecure at this point due to lack of full security updates. You can keep sandboxed Google Play working there by rejecting requests by the Play Store to update it, or reinstalling it.If you accepted these self-update requests from the Play Store on legacy 3rd generation Pixels, you need to uninstall both Play Store and Play services followed by reinstalling them from our app repository. Don't uninstall/reinstall GSF or you'll also need to uninstall/reinstall every other app depending on GSF directly.Accepting those update requests is fine with GmsCompatConfig v16 again.We do it this way is so that we're responsible for testing and approving each Play services and Play Store update through our app repository while still supporting installing additional split packages for these apps with extra locales, etc. via the Play Store. Works well again.#grapheneos #gmscompat
(DIR) Post #APkc1QtDnpEZ8jB2a8 by grapheneos@infosec.exchange
2022-11-19T04:24:29Z
1 likes, 1 repeats
We had to create a new #grapheneos:grapheneos.org chat room to work around state reset bugs in Matrix protocol / server software. Previous room had ~15000 members and is redirected through the room upgrade, but it's not seamless. You need to explicitly join the new room.List of our public chat rooms is available at https://grapheneos.org/contact#community… with links to join through the official Element web client if you're new to Matrix. It's as good a time as any to join our chat rooms. A positive side to needing a room upgrade is that the main room is faster.#grapheneos #matrix #matrixchat #matrixdotorg
(DIR) Post #APyfcio38WcaQAUyhs by grapheneos@infosec.exchange
2022-11-25T23:33:14Z
0 likes, 0 repeats
@adam @GrapheneOS@aspiechattr.meYou're responding to an unofficial account mirroring our content from Twitter against the wishes of GrapheneOS. We want this account to be turned over to us, but unfortunately whoever created it hasn't responded to our attempts to contact them. We'll have to contact the instance administrators next. Simple Mobile Tools apps do not meet our requirements. They're too barebones, missing compatibility with the standard Android intents and have anti-features include security theatre we don't want in GrapheneOS. The direction and approach taken by those apps isn't a fit for GrapheneOs.
(DIR) Post #APyfhNfBAoFEILZTVI by grapheneos@infosec.exchange
2022-11-25T23:35:01Z
0 likes, 0 repeats
@adam @GrapheneOS@aspiechattr.meYou're responding to an unofficial account mirroring our content from Twitter against the wishes of GrapheneOS. We want this account to be turned over to us, but unfortunately whoever created it hasn't responded to our attempts to contact them. We'll have to contact the instance administrators next. Simple Mobile Tools apps do not meet our requirements. They're too barebones, missing compatibility with the standard Android intents and have anti-features include security theatre we don't want in GrapheneOS. We aren't going to bundle a Calendar app that's not a replacement for AOSP Calendar as a frontend for the OS Calendar system. The direction and approach taken by those apps isn't a fit for GrapheneOS. They're heavily focused on legacy Android versions / devices too, which means they don't provide a great experience on modern Android. GPLv3 licensing is also not acceptable for GrapheneOS.
(DIR) Post #AQ1h3csxwMfXJ04SHo by grapheneos@infosec.exchange
2022-11-27T10:25:44Z
1 likes, 1 repeats
We're now hosting our own Mastodon instance at https://grapheneos.social/ and we'll be moving to @GrapheneOS@grapheneos.social from this account.Our server has closed registration and will only be used for official GrapheneOS accounts along with accounts for our project members. It's the same approach we take for our Matrix and email servers.The remaining setup work will be porting over our age-encrypted cloud backup scripts, improving the sample Mastodon nginx configuration we merged with our standard baseline configuration, tuning PostgreSQL for the instance and setting up localhost access control via nftables which is currently missing.Donations are appreciated to help cover the cost of this new infrastructure along with the time spent setting it up and maintaining it going forward:https://grapheneos.org/donate