View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0009462 | Taler | merchant backend | public | 2025-01-16 15:54 | 2025-01-16 17:57 |
| Reporter | fefe | Assigned To | Resolution deadline | ||
| Implementer | Reviewer | ||||
| Release signed by | Deployed by | ||||
| Verifier | Communicator | ||||
| Data protection authority notification required | No | ||||
| CSIRT notification required | No | ||||
| Estimated effort (hours) | Actual effort (hours) | 0 | |||
| Fast-track | No | ||||
| Work package | none | ||||
| Priority | none | Severity | feature | Reproducibility | have not tried |
| Status | acknowledged | Resolution | open | ||
| Product Version | git (master) | ||||
| Target Version | post-2.0 | ||||
| Summary | 0009462: in-band signaling in the log | ||||
| Description | Logging in the merchant backend is usually using function calls like this: ``` 874 GNUNET_log (GNUNET_ERROR_TYPE_INFO, 875 "KYC status for `%s' at `%s' is %u/%s/%s/%s\n", 876 payto_uri.full_payto, 877 exchange_url, 878 last_http_status, 879 kyc_ok ? "KYC OK" : "KYC NEEDED", 880 in_aml_review ? "IN AML REVIEW" : "NO AML REVIEW", 881 NULL == jlimits ? "DEFAULT LIMITS" : "CUSTOM LIMITS"); ``` If any of these fields are attacker controlled, they can inject escape characters or newlines into the log files, corrupting them in the process. Are these logs just informational or are they looked at for evidence collection or security purposes afterwards? If so, they should make sure to preserve the data while not allowing it to corrupt the logs. For example, they could be urlencoded or quoted printable maybe. | ||||
| Tags | No tags attached. | ||||
| We're not currently providing any assurances that the log doesn't contain newlines or other escape characters or is otherwise well-formed. The intention for now is to provide logs to help developers diagnose issues. The only "automatic" processing we do is filter by ERROR/WARNING (if these strings are anywhere on a line) to raise alerts from the monitoring that something isn't quite right. But there newlines also are no real problem, as the point is to call attention to devops people inspecting the logs. If we ever change what we do with the logs, this could be reviewed. | |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2025-01-16 15:54 | fefe | New Issue | |
| 2025-01-16 15:54 | fefe | Status | new => assigned |
| 2025-01-16 15:54 | fefe | Assigned To | => Christian Grothoff |
| 2025-01-16 15:58 | Christian Grothoff | Note Added: 0023989 | |
| 2025-01-16 15:59 | Christian Grothoff | Priority | normal => none |
| 2025-01-16 15:59 | Christian Grothoff | Severity | minor => feature |
| 2025-01-16 15:59 | Christian Grothoff | Status | assigned => acknowledged |
| 2025-01-16 15:59 | Christian Grothoff | Product Version | => git (master) |
| 2025-01-16 15:59 | Christian Grothoff | Target Version | => post-2.0 |
| 2025-01-16 17:57 | Christian Grothoff | Assigned To | Christian Grothoff => |
| 2025-03-22 13:09 | Christian Grothoff | Category | mechant backend => merchant backend |