The canonical answer is https://security.stackexchange.com/questions/70719/ssl3-poodle-vulnerability and prefers to exclude the protocol SSLv3, not ciphers.
Preliminarily, the two distinct ciphersuites you name use original DES, retronymed single-DES, and are insecure in ALL protocol versions. Original DES was replaced and withdrawn a decade ago. (More exactly FIPS46-3 was superseded by FIPS197 AES in 2001, then withdrawn in 2005, and triple-DEA only, NOT single-DEA, was republished as SP800-67 in 2004 as approved but not standard.) They are classified as LOW in openssl's cipher configuration, and along with EXPORT (even less secure) and eNULL (totally insecure) should never be configured unless you have to deal with a seriously obsolete system that can't be upgraded, replaced, or front-ended, like maybe one of the older Mars landers.
To your question, there aren't really SSLv3-specific CBC ciphers, although there kind of are non-SSLv3 ones. In openssl the configuration of allowed ciphersuites and protocols is separate and nearly independent; AFAICS the only constraints are that ciphers using new TLSv1.2 features (authenticated encryption GCM or SHA-2 hashes) can't be chosen in any older protocol, and a few ciphers used in SSLv2 but not assigned SSLv3+ codes because they were already insecure in 1996 can't be used in SSL3+. Even according to standards, the only differences for ciphers between SSL3 and TLS1 or 1.1 are:
the 40-bit EXPORT ciphers were officially deleted by 1.1 -- but openssl still supports them anyway in 1.1 and 1.2 as an extension. But they were and are insecure and you shouldn't use them unless you time-travel back to the 1990s and are subject to the legal restrictions in some places then.
the Fortezza key-exchange added to appease the USgovt during the "crypto is a weapon" period, and never used by anyone but maybe NSA, was deleted by TLS1. It is not implemented by openssl in any protocol.
the first batch of ECC ciphers in https://www.rfc-editor.org/rfc/rfc4492 officially apply only to TLS1+ because they rely on extensions in the ClientHello and https://www.rfc-editor.org/rfc/rfc3546 for extensions couldn't modify SSL3, but openssl >=1.0.0 (or some 0.9.8 if tweaked) implements them in SSL3 by treating the extensions as defaulting to "no restriction" -- but only if the peer agrees, which peers other than deliberately nobbled recent openssl probably won't. This is the only possibly useful cipher difference. Assuming an RSA cert&privatekey, you could use ECDHE-RSA and hope it only works on TLS1+.
This is why the commandline openssl ciphers -v [$cipherstring] utility shows SSLv3 as the "version" for most ciphers; it means SSLv3 AND UP.
TL-DR: IF your SSL3-only clients don't negotiate ECC ciphers (and most very old clients probably don't although nobbled newer ones may) AND ALL your TLS1+ clients DO (which is much less certain) and assuming the common case of an RSA cert&privatekey, you could enable ECDHE-RSA-(3DES or AES)-CBC but disable DHE-RSA-anything-CBC and RSA-anything-CBC. This also gives you Perfect Forward Secrecy.
If you want you could also enable RC4 for all SSL3+, with PFS or not, but there are concerns there too:
Are your "legacy applications" web or something else? If web can't you get a half-decent browser? If a custom app can't be caused to repeatedly resend the same sensitive data AFTER attacker data it isn't "biteable" in the first place.
