briar issueshttps://code.briarproject.org/briar/briar/-/issues2024-02-13T07:33:58Zhttps://code.briarproject.org/briar/briar/-/issues/2458Detect whether phone is rooted2024-02-13T07:33:58ZakwizgranDetect whether phone is rootedOWASP guidelines recommend that Android apps should detect whether the phone is rooted. There are libraries that can check for this.OWASP guidelines recommend that Android apps should detect whether the phone is rooted. There are libraries that can check for this.https://code.briarproject.org/briar/briar/-/issues/1988Notification wrongly shows app as unlocked if locked shortly after signing in2021-11-04T11:03:25ZakwizgranNotification wrongly shows app as unlocked if locked shortly after signing inA user reported that the notification shows the app as unlocked if it's locked shortly after signing in. I haven't managed to reproduce the bug yet, but the user gave these steps:
* Enable app lock
* Sign out
* Sign in
* Immediately or ...A user reported that the notification shows the app as unlocked if it's locked shortly after signing in. I haven't managed to reproduce the bug yet, but the user gave these steps:
* Enable app lock
* Sign out
* Sign in
* Immediately or after a couple of seconds open menu and press lock app
* Pull down for notifications and observe Briar notification it states "Briar is locked" and then changing into "Signed into Briar"
Reported on API 31.Android 1.4https://code.briarproject.org/briar/briar/-/issues/1500Check PNGs for exploits before passing them to Android2021-11-04T11:03:44ZakwizgranCheck PNGs for exploits before passing them to AndroidWe need to find out how to detect PNGs that can exploit this vulnerability, so we can avoid passing them to Android:
https://www.zdnet.com/article/opening-this-image-file-grants-hackers-access-to-your-android-phone/
Subtask of #1237.We need to find out how to detect PNGs that can exploit this vulnerability, so we can avoid passing them to Android:
https://www.zdnet.com/article/opening-this-image-file-grants-hackers-access-to-your-android-phone/
Subtask of #1237.Android 1.4https://code.briarproject.org/briar/briar/-/issues/1320Add backpressure to incoming sync sessions2020-11-18T01:34:09ZakwizgranAdd backpressure to incoming sync sessionsIncomingSession reads records from the transport as quickly as possible and queues them to be added to the DB. If the transport is faster than the DB, this will result in an unbounded number of records being queued. This uses an unbounde...IncomingSession reads records from the transport as quickly as possible and queues them to be added to the DB. If the transport is faster than the DB, this will result in an unbounded number of records being queued. This uses an unbounded amount of memory, which is a DoS risk.
Add a backpressure mechanism that limits the amount of queued data and delays reading from the connection when the queue is full.https://code.briarproject.org/briar/briar/-/issues/935Hostname of feed URL is logged during RSS Feed Import2020-11-19T15:22:32ZTorsten GroteHostname of feed URL is logged during RSS Feed ImportPrivacy leak?
```
04-10 15:14:04.602 D/libc-netbsd: [getaddrinfo]: hostname=www.schneier.com; servname=(null); cache_mode=(null), netid=0; mark=0
04-10 15:14:04.602 D/libc-netbsd: [getaddrinfo]: ai_addrlen=0; ai_canonname=(null); ai_flag...Privacy leak?
```
04-10 15:14:04.602 D/libc-netbsd: [getaddrinfo]: hostname=www.schneier.com; servname=(null); cache_mode=(null), netid=0; mark=0
04-10 15:14:04.602 D/libc-netbsd: [getaddrinfo]: ai_addrlen=0; ai_canonname=(null); ai_flags=4; ai_family=0
```https://code.briarproject.org/briar/briar/-/issues/604Provide hooks for mitigating flooding attacks at client layer2020-11-21T17:21:36ZakwizgranProvide hooks for mitigating flooding attacks at client layerMessage flooding attacks can be mitigated to some extent at the sync layer (#511), but the client may be in a better position to make decisions such as rate limiting. The sync API should allow clients to express these decisions, for exam...Message flooding attacks can be mitigated to some extent at the sync layer (#511), but the client may be in a better position to make decisions such as rate limiting. The sync API should allow clients to express these decisions, for example by limiting the rate at which messages are delivered to the client, shared with contacts, or both.https://code.briarproject.org/briar/briar/-/issues/511Mitigate flooding attacks at sync layer2020-11-21T18:33:47ZakwizgranMitigate flooding attacks at sync layerThe sync layer should mitigate flooding attacks by preventing any contact or group from exhausting any resource (computation, bandwidth, memory or storage).
This might be done by implementing something similar to fair queueing for each ...The sync layer should mitigate flooding attacks by preventing any contact or group from exhausting any resource (computation, bandwidth, memory or storage).
This might be done by implementing something similar to fair queueing for each resource: when the resource gets close to being fully used, prioritise demand from contacts and groups that are using less than their fair share over demand from contacts and groups that are using more than their fair share.https://code.briarproject.org/briar/briar/-/issues/58Use double MAC technique for checking MACs2020-11-21T20:17:47ZakwizgranUse double MAC technique for checking MACsComparing a received MAC to the expected MAC in constant time is tricky in high-level languages because the compiler, runtime and JIT may optimise the comparison code so that it no longer runs in constant time. The adversary may be able ...Comparing a received MAC to the expected MAC in constant time is tricky in high-level languages because the compiler, runtime and JIT may optimise the comparison code so that it no longer runs in constant time. The adversary may be able to use the timing of the comparison to discover how many bytes of the received MAC match the expected MAC.
To avoid revealing this information, the recipient can calculate another MAC over each MAC and compare the outer MACs. The adversary can use the timing of the comparison to learn the position at which the outer MACs differ, but that doesn't reveal the position at which the inner MACs differ.
https://www.isecpartners.com/blog/2011/february/double-hmac-verification.aspx
The MAC is being used as a PRF. It seems like this technique could also be used for validating signatures -- the validator can use any MAC key (not necessarily shared with the signer) to calculate MACs over the received and expected signatures, then compare the MACs.