Thread: [Lcms-user] Announcement about patches
An ICC-based CMM for color management
Brought to you by:
mm2
From: Marti.Maria <mar...@li...> - 2009-04-19 14:28:39
Attachments:
smime.p7s
|
Hi, After the bad experience of those “security” patches flying around, I would like to establish a clear process to deal with such stuff. I think security issues are real and should be addressed. And I prefer to address by myself, so you would know who to blame if anything fails. The proposed process is quite simple, if you detect a potential security issue and are able to create a patch, please send me the patch to analyse. I have an extensive test bed of apps and utilities using lcms, so I can check if all those goes fine. Please avoid advisories if possible, as doing that hints how to use the flaw for malicious use. Credits to vulnerability busters will be given on each release. After the patch proves to be harmless, I will send to the mailing list a signed mail with the patch attached. That is, you got a patch from upstream that upstream claims to be reasonably tested. I will apply the same checks that I do before a normal release. Please understand that this is a lot of work, and obviously it can fail as well, so the “no guarantee” clause of MIT license applies. If you choose to redistribute such patches, please make sure to include the mail, or at least the MIT license. There are legal issues on such patches and there have been cases of people being sued by distributing things like that. By including the MIT license you prevent to get in legal trouble. I’ve picked a report from Gentoo team, which may well serve as a test. You would not expect to have many of those reports, at least of such low severity. The issue would almost never happen because it implies a crafted monochrome profile used as output, but as said this is intended to test the process. See next a signed mail with the patch and a description of the issue. If you have any feedback of this process, please let me know. Many thanks to Robert Buchholz, from Gentoo for suggesting the signed mail approach and providing the patch. I don't know this time who discovered the flaw, so I apologize for not including him in the copyright. If you are the author, please let me know and credits will be given in next lcms release. Best regards Marti Maria The LittleCMS project http://www.littlecms.com |
From: Bob F. <bfr...@si...> - 2009-04-19 16:54:00
|
Marti, It is nice to see that you are being super-secure regarding lcms patches, but this seems a bit pointless given the way that lcms is currently distributed from a 'blind' web site (http://www.littlecms.com/downloads.htm) with no way to verify that a distribution package is current and correct. Most distribution of lcms files is independent of your web site. Including accurate release date/time information and an independent way to download a verification signature such as a MD5 or even a PGP signature would help. Today I noticed that I can also download lcms files from SourceForge. The SourceForge page says that the last update is Mar 21 2009 with release 1.18. There is no news entry for 1.18a. If I click on 1.18 I see files with 1.18a naming. So if someone has already downloaded 1.18 they really have to drill down to determine that they don't have the latest files. Bob -- Bob Friesenhahn bfr...@si..., http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer, http://www.GraphicsMagick.org/ |
From: Bob F. <bfr...@si...> - 2009-04-19 17:12:19
|
Marti, I extracted lcms-1.18a.tar.gz and notice that there are no documentation updates and that the package extracts as lcms-1.18 rather than lcms-1.18a. The only way to tell that there has been an update is that src/cmsxform.c is more recent than the NEWS file. The shared library builds with the same versioning information. This approach causes problems for users since it is difficult to tell if their installed 1.18 has the security patch or not. Bob -- Bob Friesenhahn bfr...@si..., http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer, http://www.GraphicsMagick.org/ |
From: Kai-Uwe B. <ku...@gm...> - 2009-04-19 17:59:02
|
Am 19.04.09, 12:12 -0500 schrieb Bob Friesenhahn: > I extracted lcms-1.18a.tar.gz and notice that there are no > documentation updates and that the package extracts as lcms-1.18 > rather than lcms-1.18a. The only way to tell that there has been an > update is that src/cmsxform.c is more recent than the NEWS file. The > shared library builds with the same versioning information. > > This approach causes problems for users since it is difficult to tell > if their installed 1.18 has the security patch or not. It is typical for many projects to use a major.minor.patch, e.g. 1.18.1, naming scheme for such minimal changes like e.g. security patches. But well, 1.18.1 sounds more technical otherwise it seeme very practical. kind regards Kai-Uwe Behrmann -- developing for colour management www.behrmann.name + www.oyranos.org |
From: <mar...@li...> - 2009-04-19 19:18:03
|
Ok, I will adopt the 1.18.2 naming convention for the next update, and modify the NEWS file as well. Regarding being more secure... well, this is color management and not a security package, so probably Bob is right and all this effort may be pointless. What do you think? Giving a MD5 message digest would help? Do we need anything else? Regards Marti Quoting Kai-Uwe Behrmann <ku...@gm...>: > Am 19.04.09, 12:12 -0500 schrieb Bob Friesenhahn: > >> I extracted lcms-1.18a.tar.gz and notice that there are no >> documentation updates and that the package extracts as lcms-1.18 >> rather than lcms-1.18a. The only way to tell that there has been an >> update is that src/cmsxform.c is more recent than the NEWS file. The >> shared library builds with the same versioning information. >> >> This approach causes problems for users since it is difficult to tell >> if their installed 1.18 has the security patch or not. > > It is typical for many projects to use a major.minor.patch, e.g. > 1.18.1, naming scheme for such minimal changes like e.g. security > patches. But well, 1.18.1 sounds more technical otherwise it seeme > very practical. > > > kind regards > Kai-Uwe Behrmann > -- > developing for colour management www.behrmann.name + www.oyranos.org > > |
From: Bob F. <bfr...@si...> - 2009-04-19 20:09:37
|
On Sun, 19 Apr 2009, mar...@li... wrote: > Regarding being more secure... well, this is color management > and not a security package, so probably Bob is right and all > this effort may be pointless. What do you think? Giving a MD5 > message digest would help? Do we need anything else? Lcms is important to security since ICC profiles can be contained in random files from the Internet or other untrustable sources. This is the only path which is any serious concern. Printing subsystems may also use lcms and are likely to run as a different user than the person who submitted the job, and the person who submitted the job may have done so from another machine. The printing system should be designed to limit the impact of such bugs. I create MD5 checksums for GraphicsMagick files but only as a convenience for the user. In order for the MD5 checksum to be more than a convenience it needs to be separately available from a known secure source, or signed using some other means. For example your web site is likely more trusted than some site which claims to be a mirror site. A number of Linux (and maybe some *BSD and OS-X) distributions have security problems with their packaging systems in that while they may verify the downloaded file with a MD5 checksum, the MD5 checksum itself is not signed or validated in any way and can be very easily compromised. Commercial Linux (e.g. Red Hat & SuSe) are much more secure since they don't rely on volunteer mirror sites. This situation was documented in USENIX Login several months ago. Bob -- Bob Friesenhahn bfr...@si..., http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer, http://www.GraphicsMagick.org/ |
From: Hal V. E. <hv...@as...> - 2009-04-19 20:55:38
|
On Sunday 19 April 2009 01:09:27 pm Bob Friesenhahn wrote: > On Sun, 19 Apr 2009, mar...@li... wrote: > > Regarding being more secure... well, this is color management > > and not a security package, so probably Bob is right and all > > this effort may be pointless. What do you think? Giving a MD5 > > message digest would help? Do we need anything else? > > Lcms is important to security since ICC profiles can be contained in > random files from the Internet or other untrustable sources. This is > the only path which is any serious concern. Printing subsystems may > also use lcms and are likely to run as a different user than the > person who submitted the job, and the person who submitted the job may > have done so from another machine. The printing system should be > designed to limit the impact of such bugs. Work is underway right now to make GhostScript fully compliant with the PDF V 1.7 and to write a new color management aware pdftoraster filter for CUPS based on the work being done on GhostScript. The intent is to move to a PDF based printing work flow that supports color management as part of CUPS much like the current system used on OS/X. OS/X uses CUPS and has a proprietary CUPS pdftoraster filter that does color management. The updates happening to GhostScript will utilize lcms at least initially and probably for a long time since no other open source cm engine has V4 support and lcms is the accepted standard for use on open source systems. Current GhostScript versions are using code from ArgyllCMS but only partly supports PDF v 1.3 and has no support for ICC V4 profiles. This work was discussed at length at the recent Linux Foundation Open Printing Summit in San Fransisco on April 10 but security issues were not talked about in any detail. I am sure that those working on this are very concerned about security issues related to the color management engine and profiles since this issue has been raised by the CUPS team on other email lists including the OpenICC list. So Bob's comments on this being a concern for the printing system folks is on the money. > > I create MD5 checksums for GraphicsMagick files but only as a > convenience for the user. In order for the MD5 checksum to be more > than a convenience it needs to be separately available from a known > secure source, or signed using some other means. For example your web > site is likely more trusted than some site which claims to be a mirror > site. > > A number of Linux (and maybe some *BSD and OS-X) distributions have > security problems with their packaging systems in that while they may > verify the downloaded file with a MD5 checksum, the MD5 checksum > itself is not signed or validated in any way and can be very easily > compromised. Commercial Linux (e.g. Red Hat & SuSe) are much more > secure since they don't rely on volunteer mirror sites. This > situation was documented in USENIX Login several months ago. > > Bob > -- > Bob Friesenhahn > bfr...@si..., http://www.simplesystems.org/users/bfriesen/ > GraphicsMagick Maintainer, http://www.GraphicsMagick.org/ > > --------------------------------------------------------------------------- >--- Stay on top of everything new and different, both inside and > around Java (TM) technology - register by April 22, and save > $200 on the JavaOne (SM) conference, June 2-5, 2009, San Francisco. > 300 plus technical and hands-on sessions. Register today. > Use priority code J9JMT32. http://p.sf.net/sfu/p > _______________________________________________ > Lcms-user mailing list > Lcm...@li... > https://lists.sourceforge.net/lists/listinfo/lcms-user |