I am designing a library that supports encrypting some in-memory data using AES in CBC mode. Now I need a padding but it seemed to me that Apple's CommonCrypto library and OpenSSL have different padding schemes but I want to retain interoperability even when mixing CommonCrypto implementation and OpenSSL ones. (My library should work under Linux which have only OpenSSL, iOS which have only CommonCrypto and OS X which have both.)
Given that my library already have gzip and gzip archives can still be unarchived with any byte string concatenated after it, I am considering this padding scheme:
When decrypting, the gzip algorithm will automatically discard the appended random bytes.
You are basically using gzip to convey the length of the given message. As long as your implementation of AES-CBC is secure (e.g. by using a random IV) then the given scheme should be secure against padding oracle attacks. This is easy to prove as there is nothing that removes the padding from the plaintext.
CBC padding in general does not add any security to the block cipher mode. You could just pad with zero bytes if you already know the size of the plaintext. In that sense the scheme is safe as long as no information is leaked to an attacker after decryption. Note that using gzip may influence the size of the plaintext so you need to make sure an attacker cannot learn too much from the size of the ciphertext.
Your scheme is therefore safe if the attacker only has access to the ciphertext. In that case it does provide confidentiality.
So now for the bad news...
This does not mean that the data within the ciphertext container cannot be altered. As there is no cryptographically secure authentication tag present, an attacker could very well be able to change the ciphertext in a way that cannot be detected. So the application code that processes the decrypted data could still be fooled to leak information about the plain text.
In other words, although you have now successfully protected against padding oracle attacks, you haven't protected yourself against similar, active attacks on the ciphertext. Please add some kind of secure authentication tag. It is by far the best way to protect yourself against these kinds of active attacks.