What they have found is an interface that allows the baseband software to gain access to the file system of the device. Whether or not the baseband software itself contains a remotely exploitable backdoor which then would use that API is another question that has yet to be answered.
The stuff uncovered here could genuinely be used for logging and baseband firmware updates.
True, but those functions could easily be implemented with a more restricted and secure interface (like say, a log() function and a firmwareUpdate() function, in the case of your examples). There is no sane reason to give a black-box like the baseband processor full access to the filesystem of the application processor. Especially not since the baseband can rather stealthily also be talking to outside agents.
Whether or not this was put in as a back door, whether it was exploited by someone, or whether they just created an over-broad interface for more benign features, Samsung’s at fault here as far as I’m concerned.
Well, there was no sane reason to give every process raw access to memory through the exynos device, but Samsung did that too. Security doesn’t appear high on their priority list.
Oh. I totally agree that this is bad practice, but I don’t agree with the alarmist tone of the FSF article, nor with the notion that this is a backdoor in the usual sense of the word.
I don’t see this component going any lengths in hiding its abilities nor do I see any way in how this can be remotely exploited (assuming no backdoor in the traditional sense is available to use in the baseband). As such I wouldn’t call this a backdoor, just bad engineering practice.
The word backdoor is now used to describe all software flaws. You get more clicks that way. It’s gotten so bad that if anybody does discover a real backdoor, I’m unlikely to read the article.
Wow. I suppose we always suspected there would be backdoors like this, but to see one actually exposed in the wild is kind of freaky. Samsung has a lot of explaining to do.
What they have found is an interface that allows the baseband software to gain access to the file system of the device. Whether or not the baseband software itself contains a remotely exploitable backdoor which then would use that API is another question that has yet to be answered.
The stuff uncovered here could genuinely be used for logging and baseband firmware updates.
True, but those functions could easily be implemented with a more restricted and secure interface (like say, a
log()function and afirmwareUpdate()function, in the case of your examples). There is no sane reason to give a black-box like the baseband processor full access to the filesystem of the application processor. Especially not since the baseband can rather stealthily also be talking to outside agents.Whether or not this was put in as a back door, whether it was exploited by someone, or whether they just created an over-broad interface for more benign features, Samsung’s at fault here as far as I’m concerned.
Well, there was no sane reason to give every process raw access to memory through the exynos device, but Samsung did that too. Security doesn’t appear high on their priority list.
Oh. I totally agree that this is bad practice, but I don’t agree with the alarmist tone of the FSF article, nor with the notion that this is a backdoor in the usual sense of the word.
I don’t see this component going any lengths in hiding its abilities nor do I see any way in how this can be remotely exploited (assuming no backdoor in the traditional sense is available to use in the baseband). As such I wouldn’t call this a backdoor, just bad engineering practice.
The word backdoor is now used to describe all software flaws. You get more clicks that way. It’s gotten so bad that if anybody does discover a real backdoor, I’m unlikely to read the article.
Wow. I suppose we always suspected there would be backdoors like this, but to see one actually exposed in the wild is kind of freaky. Samsung has a lot of explaining to do.