Lindner said the real problem -- a vulnerability in the way Blackberry servers handle portable network graphics (PNG) images, was not disclosed by either RIM or the US-CERT advisory.
By causing the service to render a specially crafted TIFF file, an attacker could execute arbitrary code or cause a denial of service.
Should an exploit be developed, this arbitrary code would run inside the corporate firewall on a windows system, possibly with administrator privileges, and possibly with access to the SQL server containing the encryption keys.
To disable the image attachment distiller
1. On the desktop, click Start > Programs > BlackBerry Enterprise Server > BlackBerry Enterprise Server Configuration.
2. On the Attachment Server tab, select Attachment Server from the Configuration Option drop-down list.
3. In the Distiller Settings section of the window, clear the Enabled check box for Image Attachments.
4. Click Apply, then click OK.
5. In Microsoft Windows® Administrative Tools, double-click Services.
6. Right-click BlackBerry Attachment Service, then click Stop.
7. Right-click BlackBerry Attachment Service, then click Start.
8. Close the Services window.
Note that they disable all image attachments, not just all TIFF attachments, although they do claim they only need to disable TIFF.
In summary, the CERT advisory says it might be possible to execute arbitrary code on the server. The Blackberry advisory recommends disabling all image attachment processing on the server. No one has proved that an exploit exists to take advantage of this, but how can you know there isn't an exploit. In cases like this, the burden of proof lies with the one who claims it's safe to continue processing image attachments. Maybe there isn't a serious problem. Would you leave the attachment service running with without disabling the image attachments?
Proposed revision of software signing protocols to allow for hash collisions.
Google for a25f7f0b29ee0b3968c860738533a4b9 OR a25f7f0b, an example of how to exploit a hash collision.
To avoid this exploit, the signer needs to make an unpredictable modification to the document prior to signing.
Alice and Bob use hash function H and signature function F to validate documents. Alice signs a message M by finding signature S such that F(S) = H(M). Bob accepts (M,S) as signed by Alice. Eve can calculate H(M) and F(S) but cannot find S given M.
Eve creates documents M1 and M2 which have the same hash, and asks Alice to sign M1. If Alice uses the expected hash, Eve can substitute M2 and Bob will accept (M2,S) as signed by Alice.
So Alice and Bob need to agree to a safer method. When Eve presents M1 for signature, Alice generates a new random key K, encrypts M1 with K and hashes, giving H(K(M1)). She then signs this by finding S such that F(S) = (K,H(K(M1))), and gives (S,K) to Eve.
Eve sends (M2,S,K) to Bob. Bob checks the signature by calculating F(S) and comparing it to (K,H(K(M2))).
Eve is foiled, because H(K(M1)) != H(K(M2)), even though H(M1) = H(M2).
Thus, immediately, the protocols for signing software distributions should be adjusted so that the signing authority Alice generates random key K and signs H(K(M)) instead of just H(M). The automatic software update agent Bob checks the signature (S,K) by calculating F(S) and (K,H(K(M))).
This will prevent substitution of a useful M2 for M1 by Eve, who is allowed to present an arbitrary M1 for testing and signature. Eve cannot predict K, and hence even if she can find M2 after the fact, such that H(K(M1)) = H(K(M2)), she is not allowed to change M1 after K is chosen. Hence M2 will not be useful.
Bob can safely install M1 automatically, confident that if M1 passes a simple syntax check (which M2 cannot possibly satisfy), it is the same program which Alice accepted for signature, even if hash collisions can be found.
What you propose just redefines UTC to be atomic time plus some offset, and creates something new that is exactly what UTC is now. It just shifts the problems around a little.
Ok, atomic time is TAI, and I propose UTC henceforth will be TAI + constant. That much is correct.
But I don't propose anything new which is what UTC is now. Instead, I propose specifying time zone offsets in seconds instead of hours or half hours.
We already have time zone offsets, and they already change unpredictably.
Legal time is local time. Local time is TAI + f(date,position), where f is a function of the date which is not -- and never has been -- predictable in advance.
I don't propose a something new which is exactly what UTC is now. I propose that all of the unpredictable changes should be grouped into f(date,position).
UTC should never ever have any more leap seconds. All computers should keep time in UTC, and give local time according to the time zone offset. When there would have been a leap second, instead all of the time zone offsets should be decreased by a second.
We already have to deal with the fact that local time zones change unpredictably, so the unpredictable odd leap second is no more difficult to deal with than the unpredictable change of the dates for daylight savings time.
For example, now GMT = UTC and EST = UTC - 05:00:00 (midnight in New York is 5 AM in London). After a leap second, we would have GMT = UTC - 00:00:01 and EST = UTC - 05:00:01, and midnight in New York is still 5 AM in London.
This is so obvious, it has zero chance of ever being implemented... Prove me wrong, please!
This is very true, for many systems. I
asked about this on sci.crypt
some years ago, and received a reply suggesting that some banking industry standards regard the _public_ key as a secret shared between the bank and the customer, with the private key known only by the customer. If so, at least these systems will not fail catastrophically. Factoring the public key is only possible if you know it, so a second failure (bank reveals the secret "public" key) is required before the customer's identity is compromised.
... IBM shall have the right to terminate this Agreement immediately upon the occurrence of a Change of Control of SCO
which IBM in its sole discretion determines will substantially and adversely impact the overall purpose of the cooperation... or will create a
significant risk or material and adverse exposure of IBM's confidential
and/or technical proprietary information....
Did control change from Caldera to The SCO Group?
Well, actually, control changed from Old SCO to Caldera International, Inc.
, which later renamed itself The SCO Group (SCOX). For most of the gory details of the transfer, see
the Agreement and Plan of Reorganization between Caldera and Santa Cruz Operation. Don't forget the ammendments, which were made prior to close. Old SCO
contributed all of the stock of certain of its subsidiaries to Caldera International. It certainly looks like this transaction would trigger the Change of Control clause, so that IBM would have the right to terminate the agreement. I don't know if IBM did terminate the agreement. I suppose that "immediately upon" means "immediately upon or anytime after" rather than "immediately upon, but not more than X days after..."
Case closed.
Actually, the cases aren't over, and won't be for quite a while. Even the Dalmer-Chrysler case is dragging on. Keeping the cases undecided seems to be the whole point of the exercise.
Unfortunate
Authored by: PJ on Thursday, February 26 2004 @ 06:30 PM EST
Actually, McBride was the one, I've been told, [who suggested] he speak at Harvard, not the other way around.
Slashdot Mirror
From the top of the CERT advisory:
Should an exploit be developed, this arbitrary code would run inside the corporate firewall on a windows system, possibly with administrator privileges, and possibly with access to the SQL server containing the encryption keys.From the advisory:
Note that they disable all image attachments, not just all TIFF attachments, although they do claim they only need to disable TIFF.In summary, the CERT advisory says it might be possible to execute arbitrary code on the server. The Blackberry advisory recommends disabling all image attachment processing on the server. No one has proved that an exploit exists to take advantage of this, but how can you know there isn't an exploit. In cases like this, the burden of proof lies with the one who claims it's safe to continue processing image attachments. Maybe there isn't a serious problem. Would you leave the attachment service running with without disabling the image attachments?
Google for a25f7f0b29ee0b3968c860738533a4b9 OR a25f7f0b, an example of how to exploit a hash collision.
To avoid this exploit, the signer needs to make an unpredictable modification to the document prior to signing.
Alice and Bob use hash function H and signature function F to validate documents. Alice signs a message M by finding signature S such that F(S) = H(M). Bob accepts (M,S) as signed by Alice. Eve can calculate H(M) and F(S) but cannot find S given M.
Eve creates documents M1 and M2 which have the same hash, and asks Alice to sign M1. If Alice uses the expected hash, Eve can substitute M2 and Bob will accept (M2,S) as signed by Alice.
So Alice and Bob need to agree to a safer method. When Eve presents M1 for signature, Alice generates a new random key K, encrypts M1 with K and hashes, giving H(K(M1)). She then signs this by finding S such that F(S) = (K,H(K(M1))), and gives (S,K) to Eve.
Eve sends (M2,S,K) to Bob. Bob checks the signature by calculating F(S) and comparing it to (K,H(K(M2))).
Eve is foiled, because H(K(M1)) != H(K(M2)), even though H(M1) = H(M2).
Thus, immediately, the protocols for signing software distributions should be adjusted so that the signing authority Alice generates random key K and signs H(K(M)) instead of just H(M). The automatic software update agent Bob checks the signature (S,K) by calculating F(S) and (K,H(K(M))).
This will prevent substitution of a useful M2 for M1 by Eve, who is allowed to present an arbitrary M1 for testing and signature. Eve cannot predict K, and hence even if she can find M2 after the fact, such that H(K(M1)) = H(K(M2)), she is not allowed to change M1 after K is chosen. Hence M2 will not be useful.
Bob can safely install M1 automatically, confident that if M1 passes a simple syntax check (which M2 cannot possibly satisfy), it is the same program which Alice accepted for signature, even if hash collisions can be found.
Ok, atomic time is TAI, and I propose UTC henceforth will be TAI + constant. That much is correct.
But I don't propose anything new which is what UTC is now. Instead, I propose specifying time zone offsets in seconds instead of hours or half hours. We already have time zone offsets, and they already change unpredictably.
Legal time is local time. Local time is TAI + f(date,position), where f is a function of the date which is not -- and never has been -- predictable in advance.
I don't propose a something new which is exactly what UTC is now. I propose that all of the unpredictable changes should be grouped into f(date,position).
We already have to deal with the fact that local time zones change unpredictably, so the unpredictable odd leap second is no more difficult to deal with than the unpredictable change of the dates for daylight savings time.
For example, now GMT = UTC and EST = UTC - 05:00:00 (midnight in New York is 5 AM in London). After a leap second, we would have GMT = UTC - 00:00:01 and EST = UTC - 05:00:01, and midnight in New York is still 5 AM in London.
This is so obvious, it has zero chance of ever being implemented... Prove me wrong, please!
This should be an update to the article.
This is very true, for many systems. I asked about this on sci.crypt some years ago, and received a reply suggesting that some banking industry standards regard the _public_ key as a secret shared between the bank and the customer, with the private key known only by the customer. If so, at least these systems will not fail catastrophically. Factoring the public key is only possible if you know it, so a second failure (bank reveals the secret "public" key) is required before the customer's identity is compromised.
Well, actually, it was between The Santa Cruiz Operation (Old SCO) and IBM. The unsold part of Old SCO is now known as Tarentella.
Yes. See the full text of the Monterey contract for details.
Well, actually, control changed from Old SCO to Caldera International, Inc. , which later renamed itself The SCO Group (SCOX). For most of the gory details of the transfer, see the Agreement and Plan of Reorganization between Caldera and Santa Cruz Operation. Don't forget the ammendments, which were made prior to close. Old SCO contributed all of the stock of certain of its subsidiaries to Caldera International. It certainly looks like this transaction would trigger the Change of Control clause, so that IBM would have the right to terminate the agreement. I don't know if IBM did terminate the agreement. I suppose that "immediately upon" means "immediately upon or anytime after" rather than "immediately upon, but not more than X days after..."
Actually, the cases aren't over, and won't be for quite a while. Even the Dalmer-Chrysler case is dragging on. Keeping the cases undecided seems to be the whole point of the exercise.