The medium security issues are mostly out-of-band reads, heap overflows, NULL-dereference and use-after-free security issues. Those issues should not be exploitable with ASLR [...]
Is this really valid? I remember reading numerous Google Project Zero blog posts that begin with finding an issue that should not be exploitable thanks to ASLR, and then the research would promptly proceed to defeating ASLR - usually by chaining to some unrelated and much less serious side channel exploit.
Yes/No. The issue is more about categorizing between low, medium, high and critical security issues, because this impact the bounties values.
So, we have to define some guidelines on which is high or medium, because this is the most difficult part to differentiate. OOB reads gets medium, while OOB write gets high. Buffer overflows get high, while Null-deref gets medium.
If you try hard enough, those are probably exploitable, but maybe, we're not sure. While the OOB writes are exploitable, so this is more important, so it gets high.
Of course, it is important to fix everything, but we need to be fair, notably when it is not our money.
Cannot really be said in a general way. With a lot of effort probably all of those could lead to more serious things, but not easily in a platform and setup agnostic way, i.e., you probably need time and be able to try multiple times to get you a realistic chance.
If it's not possible to try multiple times (e.g., your try crashes or runs into some other protection mechanism (no-execute flag on page set, return address validation, ...) then there's, again depending on the specifics of the bug and it's context, a very slim chance to achieve a (arbitrary) remote code execution, or something similar serious, realistically.
Also, for side channels you often need to be able to run code on the host, in some way, at which point it's probably not really interesting to exploit through VLC (as it runs normally as non-root/non-admin user anyway). Else, you'd need to be able to get some VLC responses which have a code-address related measurable characteristic (normally time-deltas), not sure if VLC can be forced to leak such infos from remote.
VLC can also connect to a remote host and play a network stream. You could probably infer delta-T through the time it takes VLC to request the next chunk of your video/audio stream.
But still, that's a long way from exposing the address of useful gadgets or other potentially sensitive information...
Comments
Is this really valid? I remember reading numerous Google Project Zero blog posts that begin with finding an issue that should not be exploitable thanks to ASLR, and then the research would promptly proceed to defeating ASLR - usually by chaining to some unrelated and much less serious side channel exploit.
(I'm the author of the blog)
Yes/No. The issue is more about categorizing between low, medium, high and critical security issues, because this impact the bounties values.
So, we have to define some guidelines on which is high or medium, because this is the most difficult part to differentiate. OOB reads gets medium, while OOB write gets high. Buffer overflows get high, while Null-deref gets medium.
If you try hard enough, those are probably exploitable, but maybe, we're not sure. While the OOB writes are exploitable, so this is more important, so it gets high.
Of course, it is important to fix everything, but we need to be fair, notably when it is not our money.
Cannot really be said in a general way. With a lot of effort probably all of those could lead to more serious things, but not easily in a platform and setup agnostic way, i.e., you probably need time and be able to try multiple times to get you a realistic chance. If it's not possible to try multiple times (e.g., your try crashes or runs into some other protection mechanism (no-execute flag on page set, return address validation, ...) then there's, again depending on the specifics of the bug and it's context, a very slim chance to achieve a (arbitrary) remote code execution, or something similar serious, realistically.
Also, for side channels you often need to be able to run code on the host, in some way, at which point it's probably not really interesting to exploit through VLC (as it runs normally as non-root/non-admin user anyway). Else, you'd need to be able to get some VLC responses which have a code-address related measurable characteristic (normally time-deltas), not sure if VLC can be forced to leak such infos from remote.
VLC can also connect to a remote host and play a network stream. You could probably infer delta-T through the time it takes VLC to request the next chunk of your video/audio stream.
But still, that's a long way from exposing the address of useful gadgets or other potentially sensitive information...
Thanks for the in-depth explanation!
Determining whether bugs are exploitable is hard: usually, the answer tends to be “yes, if you try hard enough”.
And there's a whole lot of cases where bug A isn't exploitable, and bug B isn't exploitable, but bugs A and B are exploitable.