When encoding trumps encryption (or: the latest GnuPG issue)
The latest GnuPG security advisory is, in the specific case of GnuPG, more of a "Human-Computer Interaction" than a security hole proper. The flaw is not in the encryption but in the way in which OpenPGP, a standard way of transmitting PGP-encrypted data, is interpreted by GnuPG "helpers" such as Enigmail and mail programs such as Evolution, KMail, etc.
An OpenPGP-compliant message can be made up of multiple sections, not all of which need to be signed or encrypted. The "helpers" and mail software do not use the GnuPG API correctly to interpret where the sections start and end leading to something called "injection" which is a fancy name for "adding untrusted data which is undetectable from trusted data".
Translated: you see the pretty icon telling you that the whole message is encrypted and signed whereas there is a section of it (text, image, binary, whatever) which isn't.
What if you use GnuPG "raw"? Well, the visual cues are insufficient even for an advanced user and this is why a new release of GnuPG is being distributed and relevant CVE numbers were issued.
To give you an idea of the extent of the issue here are the CVE numbers:
An OpenPGP-compliant message can be made up of multiple sections, not all of which need to be signed or encrypted. The "helpers" and mail software do not use the GnuPG API correctly to interpret where the sections start and end leading to something called "injection" which is a fancy name for "adding untrusted data which is undetectable from trusted data".
Translated: you see the pretty icon telling you that the whole message is encrypted and signed whereas there is a section of it (text, image, binary, whatever) which isn't.
What if you use GnuPG "raw"? Well, the visual cues are insufficient even for an advanced user and this is why a new release of GnuPG is being distributed and relevant CVE numbers were issued.
To give you an idea of the extent of the issue here are the CVE numbers:
- CVE-2007-1263 - for the visual distinction issues in GnuPG itself, all 4 attacks.
- CVE-2007-1264 - Enigmail improper use of --status-fd
- CVE-2007-1265 - KMail improper or non-existing use of --status-fd
- CVE-2007-1266 - Evolution improper or non-existing use of --status-fd
- CVE-2007-1267 - Sylpheed improper or non-existing use of --status-fd
- CVE-2007-1268 - Mutt improper or non-existing use of --status-fd
- CVE-2007-1269 - GNUMail improper or non-existing use of --status-fd
Keywords:
0 comment(s)
Time for an Xb0t 360?
It was only a matter of time until someone discovered an interesting vulnerability in the Xbox 360...
So, what is the cunning plan? Well, the designers of the Xbox 360 (which is, incidentally, PowerPC-based) went to extreme lengths to try to make it "unhackable" and chose a hypervisor design in which, unlike previous generations of gaming consoles, games no longer take over the system. There is a thin "operating system" which the games communicate with using a classic syscall ("excuse me Mr. kernel, could you please do something for me?").
Since everything goes via the syscall then, theoretically, all you need to do is armor the syscall to keep everything nice and secure.
Oops.
Looks like the syscall implementation didn't adequately check the parameters being passed for correctness and consistency allowing a privilege escalation attack. As a matter of fact if you read the actual description you will notice that it is a subtle bug with one instruction in the validation path only looking at 32 bits of a 64-bit register with a subsequent instruction acting on all 64 bits.
Now for the good news: this has been patched since January 7th 2007.
Can an Internet-connected games console be an interesting addition to the available systems for a botnet? Difficult question to answer trivially: there are many parameters to the game.
On the one side you have low-latency high-speed DSL lines favoured by gamers but on the other side you have a totally novel operating system which you have to develop for not to mention the connection time of these systems. What are the chances of a games console being left on 24x7 compared to a home PC on a DSL link? So we are probably back to the old story of "return on investment": is it worth my while to develop a new engine and virus to go after the Xbox 360s? Probably not, there are still plenty of Windows systems which will do just fine.
A final note: if you are technically minded the vulnerability description is very well written and a fascinating read.
So, what is the cunning plan? Well, the designers of the Xbox 360 (which is, incidentally, PowerPC-based) went to extreme lengths to try to make it "unhackable" and chose a hypervisor design in which, unlike previous generations of gaming consoles, games no longer take over the system. There is a thin "operating system" which the games communicate with using a classic syscall ("excuse me Mr. kernel, could you please do something for me?").
Since everything goes via the syscall then, theoretically, all you need to do is armor the syscall to keep everything nice and secure.
Oops.
Looks like the syscall implementation didn't adequately check the parameters being passed for correctness and consistency allowing a privilege escalation attack. As a matter of fact if you read the actual description you will notice that it is a subtle bug with one instruction in the validation path only looking at 32 bits of a 64-bit register with a subsequent instruction acting on all 64 bits.
Now for the good news: this has been patched since January 7th 2007.
Can an Internet-connected games console be an interesting addition to the available systems for a botnet? Difficult question to answer trivially: there are many parameters to the game.
On the one side you have low-latency high-speed DSL lines favoured by gamers but on the other side you have a totally novel operating system which you have to develop for not to mention the connection time of these systems. What are the chances of a games console being left on 24x7 compared to a home PC on a DSL link? So we are probably back to the old story of "return on investment": is it worth my while to develop a new engine and virus to go after the Xbox 360s? Probably not, there are still plenty of Windows systems which will do just fine.
A final note: if you are technically minded the vulnerability description is very well written and a fascinating read.
Keywords:
0 comment(s)
×
![modal content]()
Diary Archives
Comments