All these cipher suites use CBC mode, which requires padding. Padding, unless used very carefully, makes encryption vulnerable to padding oracle attacks. TLS uses CBC in a MAC-then-encrypt construction, and even one that somewhat goes out of its way to make padding oracle attacks easier, because the padding can be up to 256 bytes long.
TLS CBC cipher suites are vulnerable to the Lucky Thirteen attack. This is an implementation vulnerability: not all implementations are vulnerable to this attack. However, to protect against Lucky 13, an implementation needs to take special precautions, and these precautions make decryption significantly slower (you have to calculate up to 256 MAC values for every packet instead of just one). OpenSSL and several other popular implementations implement the necessary countermeasure, but there are other popular implementations that are vulnerable.
There is an extension to the TLS protocol called encrypt-then-MAC (EtM), which does exactly what the name suggests. With encrypt-then-MAC, only authentic ciphertexts are ever decrypted, so no padding oracle attack is possible. EtM requires both sides to support the extension, and not many TLS implementations support it, so it's of limited practical applicability. Furthermore, a lot of software that uses TLS lets the administrator configure which cipher suites are permitted, but doesn't have a control for “only permitted with EtM”, so it's hard to enforce that EtM must be used.
The easiest way to rule out attacks on CBC is to not use CBC. Restrict to cipher suites that use proper AEAD: GCM, CCM, or Chacha20+Poly1305. If you absolutely must use CBC cipher suites because some of your machines still use some antique crypto engine that doesn't support 21st century modes, make sure that all your TLS implementations either support EtM or (as a last resort due to the performance penalty) implement the Lucky 13 countermeasure.
