View Issue Details

IDProjectCategoryView StatusLast Update
0010097Talerwallet-corepublic2025-06-14 12:00
Reporteroec Assigned Tooec  
PriorityhighSeveritymajorReproducibilityalways
Status resolvedResolutionfixed 
Product Versiongit (master) 
Target Version1.0 stretch goals 
Summary0010097: remove testing-dangerously-eval from production code
DescriptionIn `packages/taler-wallet-embedded/src/wallet-qjs.ts` we find the following code:

```ts
196 const onMessage = async (msgStr: any): Promise<void> => {
197 if (typeof msgStr !== "string") {
198 logger.error("expected string as message");
199 return;
200 }
201
202 const msg = JSON.parse(msgStr);
203
...
217 try {
218 if (msg.operation.startsWith("anastasis")) {
219 // Entry point for Anastasis
220 respMsg = await handleAnastasisRequest(operation, id, msg.args ?? {});
221 } else if (msg.operation === "testing-dangerously-eval") {
222 // Eval code, used only for testing. No client may rely on this.
223 logger.info(`evaluating ${msg.args.jscode}`);
224 const f = new Function(msg.args.jscode);
225 f();
226
227 respMsg = {
228 type: "response",
229 result: {},
230 operation: "testing-dangerously-eval",
231 id: msg.id,
232 };
233 } else {
234 // Entry point for wallet-core
235 respMsg = await handler.handleMessage(operation, id, msg.args ?? {});
236 }
237 } catch (e) {
238 respMsg = {
239 type: "error",
240 id,
241 operation,
242 error: getErrorDetailFromException(e),
243 };
244 }
```

That is, a message of type `testing-dangerously-eval` will be taken to contain arbitrary javascript code in the args.jscode field, and executed.
This is a huge attack vector against wallet-core, and it can not guard against it. A potential bug on the wallet-ui side that allows for arbitrary messages to be passed on to wallet-core, would lead to remote code execution and complete loss of all coins.

This code must be removed from production.
Additional InformationWe have not tried to find a way to exploit this from any of the wallet-UI's. But the fix is easy and necessary.
TagsNo tags attached.

Activities

Florian Dold

2025-06-13 00:46

manager   ~0025233

commit 78fc99d03ccd08f39923345c965982bcfe3bd707 (HEAD -> master, origin/master, origin/HEAD)
Author: Florian Dold <florian@dold.me>
Date: Fri Jun 13 00:46:31 2025 +0200

    embedded wallet: remove testing-dangerously-eval handler
    
    Issue: https://bugs.taler.net/n/10097

Florian Dold

2025-06-13 00:49

manager   ~0025234

I've removed it, however, I'd say it doesn't provide any more attack vectors than the existing wallet-core API since:
(1) There is no strong security boundary between the UI and wallet-core
(2) The existing wallet-core API effectively provides the same capability ("complete loss of all coins") by exporting a dump of the database.

Leaving this on feedback, to make sure we're on the same page w.r.t. the threat model here.

oec

2025-06-13 12:10

developer   ~0025236

Last edited: 2025-06-14 11:59

You are correct: given the current trust relationship between the wallet-UI and wallet-core, it could already f.e. export all the coins.
But, hypothetically, when that trust relationship between wallet-ui and wallet-core should change, that code path would become an attack vector.
There is also the aspect that this might allow low-privileged Apps on the phone to elevate their privileges, by exploiting this (if accessible via intents, f.e.).
Also, given the modular design, wallet-core might be used in other circumstances, with different trust boundaries.

Issue History

Date Modified Username Field Change
2025-06-12 12:37 oec New Issue
2025-06-12 15:00 Christian Grothoff Assigned To => Florian Dold
2025-06-12 15:00 Christian Grothoff Status new => assigned
2025-06-13 00:46 Florian Dold Note Added: 0025233
2025-06-13 00:49 Florian Dold Note Added: 0025234
2025-06-13 00:49 Florian Dold Assigned To Florian Dold => oec
2025-06-13 00:49 Florian Dold Status assigned => feedback
2025-06-13 12:10 oec Note Added: 0025236
2025-06-13 12:11 oec Note Edited: 0025236
2025-06-14 11:59 oec Note Edited: 0025236
2025-06-14 12:00 oec Status feedback => resolved
2025-06-14 12:00 oec Resolution open => fixed