This Ars Technica article reveals the likelihood that CPU based random number generators "RDRAND" and "Padlock" have been crafted with NSA input to benefit NSA code cracking.
Do the current Ubuntu distros utilize those routines on machines with Intel and VIA CPUs?
If so, can those generators be bypassed by installing other code?
A search on "random number" did not reveal either, and since privacy is important to many, I do believe this is of general interest and not an obscure issue.
The source of random numbers in Ubuntu come from the Linux kernel, specifically /dev/random and /dev/urandom (pseudo-random). The difference between the two is that /dev/random may be blocking while /dev/urandom does not but may not be as random.
That aside, RdRand is just one of many sources of entropy used in the Linux kernel and as long as userspace applications don't use RdRand directly but make a system call to the kernel, there is no issue with Ubuntu's random output.
Here is a link to Slashdot story where Linus explained why a petition removing RdRand from the kernel would be stupid
Linux (Ubuntu or otherwise) can use many sources of entropy to generate random numbers, including the timing of hardware access such as key presses and mouse movements, as well as a hardware generator such as RdRand if available. Entropy is also saved from one boot to the next.
If done right (and Linux does it right — not perfect, but good enough to combat the threat of a backdoored hardware RNG), combining different sources of entropy can only make for better entropy, not worse. Indeed, it is expected that the sources of entropy are individually not good enough, and only their combination is. So even if RdRand is crippled and has less entropy than the hardware manufacturer pretends, this does not weaken Linux's random number generator.
For a more in-depth explanation, see Could RDRAND (Intel) compromise entropy?
There is an indirect threat which is that none of the sources of entropy are good enough. It isn't that RdRand is compromised in itself, but that a system might be counting on it as its sole good entropy source. This is especially likely on an embedded system which lacks other hardware that exhibits randomness. Feeding /dev/random entropy pool? has some suggestions of additional entropy sources.