|
| 1 | +--- |
| 2 | +gem: avo |
| 3 | +cve: 2023-34102 |
| 4 | +ghsa: 86h2-2g4g-29qx |
| 5 | +url: https://github.com/avo-hq/avo/security/advisories/GHSA-86h2-2g4g-29qx |
| 6 | +title: avo possible unsafe reflection / partial DoS vulnerability |
| 7 | +date: 2023-06-06 |
| 8 | +description: | |
| 9 | + ### Summary |
| 10 | +
|
| 11 | + "The polymorphic field type stores the classes to operate on when updating |
| 12 | + a record with user input, and does not validate them in the back end. |
| 13 | + This can lead to unexpected behavior, remote code execution, or |
| 14 | + application crashes when viewing a manipulated record. |
| 15 | +
|
| 16 | + ### Details |
| 17 | +
|
| 18 | + After reviewing the polymorphic field implementation and performing |
| 19 | + some black box approaches, we identified a potential security issue |
| 20 | + related to the use of safe_constantize / constantize. This Rails |
| 21 | + functionality is capable of searching for classes within the Rails |
| 22 | + context and returning the class for further use. Because Avo does |
| 23 | + not validate user input when updating or creating a new polymorphic |
| 24 | + resource, it is possible to create database entries with completely |
| 25 | + different or invalid class names than the preselected ones. Avo |
| 26 | + assumes that the class specified by the user request is a valid one |
| 27 | + and attempts to work with it, which may result in dangerous behavior |
| 28 | + and code execution. |
| 29 | +
|
| 30 | + ### PoC |
| 31 | +
|
| 32 | + \n_In the test scenario we choose the demo app and the review resource which has a polymorphic |
| 33 | + reviewable field._\n_Intercepting |
| 34 | + the request and switching the review[reviewable_type] from “Fish” |
| 35 | + to “File” which is a real class inside Rails_\n_Corrupting |
| 36 | + the database with unusable classes will cause a crash at the |
| 37 | + application while viewing the new record or the index |
| 38 | + view (partial DoS)_\n\n\n_Manual |
| 39 | + delete the corrupted resource in order to recover the applications functionality_\n\n\n_Of |
| 40 | + course it is possible to use other class names or namespaces. The |
| 41 | + local development environment displays the backend error message |
| 42 | + when visiting a corrupted record. Avo is trying to apply a scope to |
| 43 | + this class that does not exist._\n\n\n_Specifying |
| 44 | + an invalid class name in the parameter will cause the application |
| 45 | + to crash again while trying constanize the provided string_ |
| 46 | +
|
| 47 | + ### Impact |
| 48 | +
|
| 49 | + The final exploitation of this vulnerability requires more time than |
| 50 | + is provided in this assessment, but initial testing of the post request |
| 51 | + shows the potential critical risk. The classes could be instantiated |
| 52 | + at any point in the code and this could also lead to code execution. |
| 53 | +
|
| 54 | + ### Recommendation |
| 55 | +
|
| 56 | + Avo should be configured to never trust user-supplied input, especially |
| 57 | + when defining classes for records. In this particular case, Avo can |
| 58 | + evaluate the options list given for the polymorphic field and only allow |
| 59 | + strings from that list. With this white-list approach, an attacker |
| 60 | + cannot supply unintended classes." |
| 61 | +cvss_v3: 8.3 |
| 62 | +patched_versions: |
| 63 | + - ">= 2.33.3" |
| 64 | +related: |
| 65 | + url: |
| 66 | + - https://github.com/avo-hq/avo/security/advisories/GHSA-86h2-2g4g-29qx |
| 67 | + - https://nvd.nist.gov/vuln/detail/CVE-2023-34102 |
| 68 | + - https://github.com/avo-hq/avo/commit/ec117882ddb1b519481bdd046dc3cfa4474e6e17 |
| 69 | + - https://github.com/avo-hq/avo/releases/tag/v2.33.3 |
| 70 | + - https://github.com/advisories/GHSA-86h2-2g4g-29qx |
0 commit comments