The only way to solve this is to use framerate dependent physics. It's one of the few cases where you should avoid dt.
The Box2D manual explains this issue a bit:
ox2D uses a computational algorithm called an integrator. Integrators simulate the physics equations at discrete points of time. This goes along with the traditional game loop where we essentially have a flip book of movement on the screen. So we need to pick a time step for Box2D. Generally physics engines for games like a time step at least as fast as 60Hz or 1/60 seconds. You can get away with larger time steps, but you will have to be more careful about setting up the definitions for your world. ... generally you should use a time step no larger than 1/30 seconds
Basically physics engines become unstable with large time steps. I guess the error compared to the "true" result gets really big. If you use dt as the time step, then the FPS gets really low, dt becomes big and the physics will become unrealistic. The only solution is to use a fixed timestep and let the game go in to slow-motion. (Increasing the iterations to improve the simulation quality will reduce the FPS even more!) 10 FPS is usually unplayable anyway, are users really getting that bad results?
The Box2D manual actually recommends against a variable time step for stability reasons (and dt can have quite a lot of variation). That's part of the reason physics defaults to a fixed timestep. It's still nice to have framerate independence, but I guess Physics is unique in that it can cause problems, and it might be less bad to use fixed stepping.
Edit: I guess we could add a maximum time step for Physics, to be 1/30. So it's framerate independent down to 30 FPS, then slows down the motion beneath that.