Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

> 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.


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.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: