Post APg0mSGzu2Ym9OSA5Y by grapheneos@infosec.exchange
(DIR) More posts by grapheneos@infosec.exchange
(DIR) Post #APe5kEZzxHIMYYBIVk by grapheneos@infosec.exchange
2022-11-16T01:17:16Z
2 likes, 2 repeats
We independently discovered the Android lockscreen bypass fixed in Android's November security update while working on features like a duress PIN/password.We had an initial patch developed by June 13 but by the time we submitted an upstream bug report, it was a duplicate issue.
(DIR) Post #APe5xZWNPEmrGnqaBM by grapheneos@infosec.exchange
2022-11-16T01:17:28Z
1 likes, 1 repeats
Can see the patch shown here was authored June 13th and it took a while for it to be developed and tested. Unfortunately, by prioritizing developing a fix for GrapheneOS users and not getting it immediately reported upstream our developer missed out on a life changing bug bounty.
(DIR) Post #APe5zF9c6MNEgJzs8m by grapheneos@infosec.exchange
2022-11-16T01:17:41Z
1 likes, 1 repeats
The developer who discovered this issue for us as part of their work on developing features like a duress PIN/password lives in India. They started out working on GrapheneOS as a volunteer, and as with most regular contributors now receive $1250/month from GrapheneOS donations.
(DIR) Post #APe60gF0sUZiyqCwPg by grapheneos@infosec.exchange
2022-11-16T01:17:51Z
1 likes, 1 repeats
$70k would be have a life changing amount of money for them. This makes us wonder how many other bug bounties we've narrowly missed out on by prioritizing GrapheneOS users. Not submitting a stub issue report ASAP was a mistake, as were other things that went wrong with this.
(DIR) Post #APe60hG75t388XjKlc by grapheneos@infosec.exchange
2022-11-16T01:18:05Z
1 likes, 1 repeats
We're aware of multiple other unfixed Android vulnerabilities. Some of these were closed as duplicates or rejected as valid issue reports upstream. Others haven't been filed upstream. Our experience filing them upstream is very poor and we already have a huge workload without it.
(DIR) Post #APe60i1yDxKYWy7YMS by grapheneos@infosec.exchange
2022-11-16T01:18:14Z
1 likes, 1 repeats
GrapheneOS receives very little funding for our substantial work on developing massive privacy and security improvements for Android (https://grapheneos.org/features). It's entirely supported by donations (https://grapheneos.org/donate). We don't want to refocus from our work to bug bounties.
(DIR) Post #APe60jVmiam17j4sTI by grapheneos@infosec.exchange
2022-11-16T01:18:28Z
2 likes, 2 repeats
It's unfortunate that there isn't funding for our developer to work on developing duress features and overall lockscreen security improvements, but instead finding a symptom of a systemic issue could have gotten them $70k if they had focused on filing that upstream ASAP instead.
(DIR) Post #APe8Kta5Br0y3LpW4m by grapheneos@infosec.exchange
2022-11-16T01:39:55Z
1 likes, 1 repeats
@fox We're fixed several of them in GrapheneOS already and we'll work on fixing the remaining issues. We're only going to push hard to get issues fixed upstream when they're firmware issues, etc. we can't simply fix ourselves downstream. We aren't going to waste our limited resources trying to fight with them over issues we can fix downstream.
(DIR) Post #APe9y59QCtabBVboZM by grapheneos@infosec.exchange
2022-11-16T01:52:58Z
0 likes, 0 repeats
@fox https://grapheneos.org/releases#2022110600 is essentially disclosure of an upstream privacy flaw and we have a bunch of similar fixes we ship and include in the release notes.We try to include every functional change in our release notes and sometimes even non-functional ones like improving code quality so that the people helping with testing know what they should focus on.
(DIR) Post #APe9y5duNXyYi3sA5Y by grapheneos@infosec.exchange
2022-11-16T01:57:16Z
1 likes, 1 repeats
@fox https://grapheneos.org/releases#2022111000 is our latest release where we shipped the December kernel security patches early for the devices with relevant patches. In that case, they're the ones who are breaking their own embargo which they do regularly for the kernels since the final couple betas for quarterly (QPR) and major yearly releases usually include the kernel that will launch with them in 1-2 months... including the embargoed security patches.
(DIR) Post #APfwlUiavWplcyeF3A by grapheneos@infosec.exchange
2022-11-16T19:48:30Z
0 likes, 0 repeats
@fox @sirdarckcat We don't particularly care about getting CVE assignments and don't bother with it especially since doing that has become a lot more painful. We care about fixing issues for GrapheneOS users and getting funding for GrapheneOS.Most of our developers are currently living on 1250 USD / month for full time work and that's draining donations (our only source of revenue in practice) faster than we're receiving them. People shouldn't have to give up getting paid properly to work on an open source project not belonging to a large corporation like Google where only things aligned with their goals can be done.
(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 #APfwlfv3HYKoMnYqUi by sirdarckcat@infosec.exchange
2022-11-16T22:32:32Z
0 likes, 0 repeats
@grapheneos @fox using vulnerability disclosure as a marketing tool is not new, but, I'm not sure it'll be well received by the community. It's more defensible to do full disclosure for the merits of full disclosure (that'll get you support from the community), but doing full disclosure for marketing, well... That will put the community against you.There's plenty of good reasons to do full disclosure.. it'll just be hard for you to say you are doing it for the right reasons now that you said it's for marketing.. :-/https://www.kialo.com/what-is-the-right-vulnerability-disclosure-policy-7258 has an argument map.
(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 #APfxSkqop10g797gDw by sirdarckcat@infosec.exchange
2022-11-16T22:47:35Z
0 likes, 0 repeats
@fox @grapheneos I mean, they are free to do what they want with their bugs 🙂. I just feel like the community won't be standing on their side if they think it's putting some users at risk for their own sake.One thing I did want to mention is that seeing a pattern doesn't necessarily mean there's someone pulling strings behind the curtain.https://www.nationalgeographic.com/science/article/lacking-control-drives-false-conclusions-conspiracy-theories-and-superstitions
(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 #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 #APfyePWW2hOvOhkS8W by sirdarckcat@infosec.exchange
2022-11-16T23:02:43Z
0 likes, 0 repeats
@grapheneos @fox Reporting a vulnerability privately and then disclosing it when the bug is fixed publicly (or after a deadline) is possible to do regardless of how bulletins work. These are independent components. One is letting the vendor know about a bug. The other is the vendor letting users know about a bug.They are somewhat related, but the merits of one aren't relevant to the other. They can be discussed in isolation.
(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.