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.