This raises the question of: why is Spotify on HTTP for the first seconds? Would it be to bypass the TLS handshake, hence a faster "start" time? Wouldn't a constant connection (à la WebSocket with TLS) fix this?
AFAIK the Spotify apps already use a persistent connection to their messaging service to facilitate instant, cross-device changes when you do something like saving a track to your library.
Is it really that concerning? What's the worst case scenario here? If the worst thing that can happen is you get served audio that you weren't expecting then I don't really see the big deal. I'm not immediately aware of any way that someone might use this as an attack vector, but then I'm not really a security guy..
If say, Spotify used a vulnerable audio decoder (or called into an OS one that was vulnerable), it could be used by an attacker to deploy an exploit against your device.
Now - is that very likely? Probably not, even if such a vulnerability exists modern exploit mitigation tactics often are able to prevent it from becoming very harmful. But it's worst case.
Android itself has had big media decode vulnerabilities in the past (looking at you libstagefright) but they basically turned out not to be readily exploitable due to ASLR on modern devices.
> Android itself has had big media decode vulnerabilities in the past (looking at you libstagefright) but they basically turned out not to be readily exploitable due to ASLR on modern devices.
That's what the optimist says.
The pessimist says, "Android itself has had big media decode vulnerabilities in the past and they only turned out not to be readily exploitable due to ASLR on modern devices".
Haha, yeah, I was actually sort of looking forward to the fallout from an MMS worm, brings back the good ol' days of Blaster and Sasser. Might have beat Android updates into shape too.
Edit: the HTTP vs HTTPS is interesting. My guess is because it is slightly cheaper to use HTTP and they serve a fuck load of music. But this only saves you from MITM attacks. People can still grab music out of their cache. So confusing.
I would like to know why too. Perhaps the Spotify devs should look into another way to secure traffic if TLS adds too much latency (such as the noise protocol)?
Maybe because of captive portals? Anyone connected to hotel wifi for example will just get an unresponsive application if it doesn't try to connect over http before switching to tls. Not sure Spotify should trust that connection as much as it appears to though.
Also, as long as it's only streaming audio over http (no auth details etc) the security risk is fairly low considering the added overhead, so it might not be a terrible decision.
I'm not sure if Spotify does this, my experience is mostly in video, but if some or all content is going to be encrypted, you start with a small http/unencrypted section and then get the license to play the encrypted part. This is because you can put the unencrypted section on a edge CDN but getting a license is going to have to go through a server that could have some significant time (say up to a couple of seconds depending). This makes it so you start right away (better UX).
I do have some experience in music, and this is likely for uncompressed or hidef playback. Some labels force encryption for hidef (but in general most of the music services stream straight progressive unencrypted even though their contracts require encryption in all cases).
Edit: but doing this is really tough. You're going to need to stitch together those two stream without a gap. This takes a lot of engineering. I've done this in flash and pure js. So this is not an arbitrary decision.
Couldn't the preview always end after N seconds, and the licensed stream always begin at the very next frame? Then it's just a matter of appending the licensed stream to the playback buffer after exhausting the preview stream.
Apart from being a very funny, this is a very nice MiTM "Hello World". A real-world application of something that is not very easy and straight forward. I remember trying to learn this stuff a few years ago and could never find a simple way of doing it.
Kind of a lot to ask but I'm fairly new to this kid of stuff (especially mitmproxy) and would love to try it out. Unfortunately the instructions on git hub aren't very in-depth. Do you have any advice for me to learn and execute this?
30 comments
[ 3.0 ms ] story [ 76.7 ms ] threadNow - is that very likely? Probably not, even if such a vulnerability exists modern exploit mitigation tactics often are able to prevent it from becoming very harmful. But it's worst case.
Android itself has had big media decode vulnerabilities in the past (looking at you libstagefright) but they basically turned out not to be readily exploitable due to ASLR on modern devices.
That's what the optimist says.
The pessimist says, "Android itself has had big media decode vulnerabilities in the past and they only turned out not to be readily exploitable due to ASLR on modern devices".
Unfortunately that dream never came to light.
http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-2...
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-2462
Edit: the HTTP vs HTTPS is interesting. My guess is because it is slightly cheaper to use HTTP and they serve a fuck load of music. But this only saves you from MITM attacks. People can still grab music out of their cache. So confusing.
Also, as long as it's only streaming audio over http (no auth details etc) the security risk is fairly low considering the added overhead, so it might not be a terrible decision.
I do have some experience in music, and this is likely for uncompressed or hidef playback. Some labels force encryption for hidef (but in general most of the music services stream straight progressive unencrypted even though their contracts require encryption in all cases).
Edit: but doing this is really tough. You're going to need to stitch together those two stream without a gap. This takes a lot of engineering. I've done this in flash and pure js. So this is not an arbitrary decision.
Obviously the NSA would.
Edit: exclusives. https://qz.com/949942/spotifys-new-deal-with-universal-gives...
Really great stuff.