As part of my commitment to OpenStreetMap-NextGen migration, I undertook a comprehensive security review of the existing OpenStreetMap website. I followed the principles of coordinated vulnerability disclosure, working directly with the maintainers to responsibly report my findings. Today, I’m making the details of this process public and verifying the status of the fixes.

Disclosure Timeline

• 2023-11-04 - Contacted Ruby security maintainers & disclosed the timeline publicly
• 2023-11-08 - Maintainers acknowledged the report
• 2023-12-04 - Reported additional vulnerabilities with a 3-month deadline
• 2023-12-06 - Maintainers acknowledged the additional report
• 2024-03-02 - Publicize vulnerability details
• 2024-03-15 - Publicize vulnerability details

---

1. Plain-Text Authentication Token Storage

Authorization tokens (oauth, session, user tokens) are stored in plain text. Read access to the database allows full impersonation of any user.

Status as of 2024-03-15: Partially vulnerable (oauth still depends on plain text storage)

NextGen Codebase Status: Fixed (all authorization tokens and credentials are hashed or encrypted for secure storage)

2. Insecure Email Reply Address Tokenization

The tokens used to ensure the authenticity of email replies are too short (24-bit), making them susceptible to brute-force attacks. An attacker could potentially guess the token and impersonate a legitimate user in email conversations. This vulnerability is especially dangerous if the attacker already has access to a conversation’s metadata (allowing for complete security bypass).

Status as of 2024-03-15: Fixed (now with 48-bit security)

NextGen Codebase Status: Fixed (128 or 256-bit security; undecided)

3. Unbounded GPX Extraction Denial of Service

The OpenStreetMap website does not impose limits on the number of files that can be extracted from a GPX archive. Attackers can exploit this by uploading specially crafted archives containing a massive number of files, potentially overwhelming the system and causing it to crash.

Status as of 2024-03-15: Mostly vulnerable (a partial fix limits points within trace files but does not fully address the issue)

NextGen Codebase Status: Fixed

4. Notes Search Query Denial of Service

The /api/0.6/notes/search endpoint is poorly optimized. This allows attackers to craft specific search queries that are extremely resource-intensive, effectively using the search feature to launch a denial of service attack.

Status as of 2024-03-15: Vulnerable

NextGen Codebase Status: Not yet tested

5. String Comparison Timing Attack

The way the code compares strings can, under certain circumstances, leak timing information. When attackers can carefully measure these timing differences, they might be able to extract secret information, such as security keys and tokens.

Status as of 2024-03-15: Fixed

NextGen Codebase Status: Fixed

6. User Block and Rate Limit Bypass

A loophole exists where a malicious user can repeatedly delete and recreate their account (using the same credentials) to circumvent security measures like user blocks and rate limits.

Status as of 2024-03-15: Fixed

NextGen Codebase Status: Not yet tested

7. Application Preference Leakage

OpenStreetMap allows different applications to store user preferences. A flaw exists where any application can access preferences created by a different application. This could leak information, and might be abused to attack other vulnerable applications that mistakenly trust data stored in user preferences.

Status as of 2024-03-15: It’s intended behavior

NextGen Codebase Status: Fixed (in API 0.7; via optional preference partitioning)

8. Unrestricted Email Checking via Password Recovery

The password recovery feature can be abused to check if any arbitrary email address is associated with an OpenStreetMap account.

Status as of 2024-03-15: Fixed

NextGen Codebase Status: Fixed

9. Forced Downgrade from OAuth1.0a to OAuth1.0

Under specific conditions, the authentication protocol can be downgraded from the more secure OAuth1.0a to the less secure OAuth1.0. This downgrade would omit important security checks.

Status as of 2024-03-15: Fixed

NextGen Codebase Status: Fixed

10. Insufficient User Token Integrity Checks

Tokens, used for things like password resets or confirming email changes, aren’t properly differentiated. An attacker might be able to use a password reset token to change an email address, or vice-versa.

Status as of 2024-03-15: Fixed

NextGen Codebase Status: Fixed

11. Inadequate Randomness Source in Token Generation

The system generating security tokens relies on a weak source of randomness. Predictable tokens are much easier for attackers to guess or manipulate.

Status as of 2024-03-15: Fixed

NextGen Codebase Status: Fixed

12. Unicode Normalization Flaw Allowing Email/Display Name Duplication

The lack of Unicode normalization means a user can register with an email address or display name that is identical to an existing one (but uses different Unicode characters). This could be used to trick users or bypass database restrictions.

Status as of 2024-03-15: Fixed

NextGen Codebase Status: Not yet tested

---

Support the NextGen development

I work on the OpenStreetMap-NextGen full-time. If you find my work valuable, please consider supporting the development on Liberapay or GitHub. Every contribution helps push us closer to that first stable release. Thank you! 🦀

And a huge thank you to those who have already supported me!

Submit a correction

If you find any inaccuracies or have suggestions to improve this diary, please feel free to contact me via https://monicz.dev/#get-in-touch.

Disclaimer

Please note that this project is not affiliated with the OpenStreetMap Foundation. It’s the result of my voluntary work and personal choices.