Not really. If you can overwrite the return address, and you have some time to plan out your payload in advance, you can write a program by “returning” into other bits of the program or its libraries.
Return Oriented Programming (ROP) can bypass the non-executable stack protection, since existing "gadgets" from program memory are executed rather than attacker-provided shellcode.
However the stack protection will probably require a separate information leak (to find the canary value) or arbitrary write (to overwrite it) to bypass. Unless the attacker is fortunate to find an unprotected function which the compiler missed, or a value that can be overwritten which changes the control flow and isn't protected by the canary.
ASLR is also a decent mitigation against ROP, and requires an information leak so the exploit code can calculate the memory offset to find the library gadgets.
In short, ROP isn't the solution to all the mitigations the parent posted; in fact ASLR is designed to make ROP harder to exploit.
If you're exploit using existing code (which would be limited), but if you want to inject code you typically need to put on the stack. Maybe one could inject code into the .bss/.data section, but this is probably protected from execution as well. The .text section is probably read only.
Think I actually looked at this and an (at the time) recent 0day for opensshd that was found and written up by a couple of Finnish students - as a motivational presentation for PaX and/or grsecurity while at university.
Fully automating ROP is difficult, but people have written many scripts to find interesting "gadgets" that set various registers and also found useful "targets" to ROP to, such as a handful of instructions inside of most libc's system command that can yield a shell if jumped to with light constraints.
