A number of temporary file bugs have been found in versions of NetPBM. These could make it possible for a local user to overwrite or create files as a different user who happens to run one of the the vulnerable utilities. http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2003-0924 http://www.kb.cert.org/vuls/id/487102 https://rhn.redhat.com/errata/RHSA-2004-031.html ------- Additional Comments From jpdalbec 2004-02-03 10:47:02 ---- Red Hat has sort of fixed some of these by adding $$ to the filename, but that's not as secure as using mktemp(1) or mkstemp(3). Also the Debian patch is limited to the DFSG-free components of netpbm and doesn't address (for example) ppmtompeg/mpeg.c writing to /tmp/fubahr. ------- Additional Comments From jkeating 2004-02-03 17:09:37 ---- Information passed on to RH package manager. ------- Additional Comments From jpdalbec 2004-02-25 06:46:52 ---- My mistake. I was looking at the patch from the Debian package instead of the -debiansecurity patch from the RHL 9 erratum. Also, the /tmp/fubahr stuff is "#ifdef BLEAH"d out. Seems like an odd way to maintain code. I've built RHL 7.3 RPMs with the -debiansecurity patch from the RHL 9 package. I had to remove one "hunk" of Alan Cox's -security patch so that the -debiansecurity patch would apply cleanly. -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 RH 7.3 (S)RPMs: f39abec5e4e2cfa191d42c870e870f859ba7b3a4 http://cc.ysu.edu/~jpdalbec/netpbm-9.24-10.73.1.legacy.i386.rpm d4c54ba9074bb57571c1b251457d9378712cef1a http://cc.ysu.edu/~jpdalbec/netpbm-9.24-10.73.1.legacy.src.rpm 284421ac5b8dc06478c94817fe41b6273f791bab http://cc.ysu.edu/~jpdalbec/netpbm-devel-9.24-10.73.1.legacy.i386.rpm 742fd35c0103e265decb4f901b9bdd2571ab81f0 http://cc.ysu.edu/~jpdalbec/netpbm-progs-9.24-10.73.1.legacy.i386.rpm They installed OK on my machine. How do I test them? The ldd output matches. Many of the programs differ. Does ELF include a timestamp? -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQFAPM8cJL4A+ldA7asRAmzZAJ0cEWCtRxn3uu02gdh5S8pzBU4khgCfcjwA krjtVkZ+pob5k0lWkQC89w4= =+L8l -----END PGP SIGNATURE----- ------- Additional Comments From michal 2004-02-27 07:25:49 ---- Changes in netpbm-9.24-debiansecurity.patch, although undoubtely handling temp files in a much more secure way, create all temporary files in subdirectories of the current working directory without a possibility of an override. This will break miserably, for example, when you happen to be positioned in a read-only file system; say, processing pictures from CD and writing on stdout. There are other failure modes (quota, space on a file system ...). One strange exception is ppm/ppmtompeg/parallel.c where location of temp files is hardwired to /tmp for a change and also without a possibility of a override (through a TMPDIR environment variable, for example). This is also a bug. All of this is rather simple to fix. ------- Additional Comments From jpdalbec 2004-03-01 10:07:15 ---- OK, there's an additional bug. In Red Hat 7.3 and 8.0, mktemp(1) doesn't recognize the -t option. Does it recognize it in Red Hat 9? What does it do? ------- Additional Comments From jpdalbec 2004-03-01 10:31:38 ---- http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=115314 Red Hat plans to release updates to mktemp and NetPBM that will fix that bug. As for the writing-to-cwd issue, I recommend you head over to bugzilla.redhat.com and file a bug report against Red Hat 9. ------- Additional Comments From michal 2004-03-01 11:04:05 ---- Ah, but there is no bug in a patch for FC1 (and likely for Red Hat 9 as well). I should have read that patch more carefuly. The thing is that 'mktemp -t ...' means: ..... -t Generate a path rooted in a temporary directory. This directory is chosen as follows: [ a three-steps rule for a directory choice skipped ] ..... but there is no '-t' option for 'mktemp' at least in 7.3. The only imperfection in a patch for RH9 seems to be that for 'parallel.c' a temporary directory is "hardwired" to /tmp and a possible TMPDIR setting is ignored - which may possibly cause some surprises but that possibility seems to be remote. I should have soon another proposition for that patch. ------- Additional Comments From michal 2004-03-01 12:57:04 ---- Created an attachment (id=564) another version to patch insecure use of temporary files This version of that patch applies on the top of sources for netpbm-9.24-9.73.2. It at least compiles correctly, it does not use mktemp flags not present in RH73, and it fixes "temporaries in the current directory" problem in ppmfade. It should be ok for 7.2 and 8.0 but this needs checking. I left alone hardwired /tmp in parallel.c. Volunteers? ------- Additional Comments From bugs.michael 2004-03-11 18:06:19 ---- Created an attachment (id=577) patch for parallel.c ------- Additional Comments From bugs.michael 2004-03-11 18:14:12 ---- Created an attachment (id=578) patch for parallel.c maybe too paranoid... feel free to be inspired ------- Additional Comments From michal 2004-03-11 20:25:59 ---- Actually not paranoid enough, I think. There is no guarantee of a null termination after 'strncpy(...)', and you do not control how long is a string from getenv("TMPDIR"), so without fileName[PATH_MAX] = '\0'; you do not know that 'strcat' will not overflow. The whole result should not be longer than PATH_MAX anyway hence the assignment above will be needed for the second time. I knew why I left that part alone. :-) ------- Additional Comments From skvidal.edu 2004-04-30 21:10:49 ---- Status Check - can someone fill in what's up here? ------- Additional Comments From michal 2004-05-02 14:55:13 ---- Created an attachment (id=647) patch to fix tmpfiles creation in parallel.c After a patch from a comment #8 was applied then this patch on the top of it should resolve TMPDIR handling in parallel.c. I believe that now this is correct. At least it compiles without complaints. :-) ------- Additional Comments From michal 2004-05-05 08:50:10 ---- Created an attachment (id=652) Spec file for a fixed netpbm - 7.x distros This is a proposed spec file for a netpbm. This goes on the top of netpbm-9.24-9.73.2 RH7.3 update from April 2003. Referenced in this spec netpbm-9.24-debiansecurity.patch and netpbm-9.24-tmpfile.patch correspond to patches from comment #8 and comment #13. This worksforme(tm) but I have no idea about versions and requirement on RH8 installation. An update for RH9 was issued quite a while ago (without touching parallel.c, IIRC). Could somebody with RH8 please check that? ------- Additional Comments From jkeating 2004-05-18 17:43:26 ---- In reply to comment #18, now that we own RHL9, would you be so kind as to produce the parallel.c patch for RHL9 as well, and we can release this all in one shot, 7.2-9 with patches/packages provided here? ------- Additional Comments From michal 2004-05-19 18:54:30 ---- I checked sources for netpbm as used in RH7.x and RH9 distros. They are in principle the same, based on netpbm-9.24 with the following exceptions: - netpbm-9.24-10.90.1 includes _smaller_ version of netpbm-9.24-security.patch (22563 bytes from Feb 19 2003, vs. 130394 bytes from Feb 28 2003 in netpbm-9.24-9.73.2). The bigger version of this patch includes everything what smaller one plus assorted fixes from Alan Cox to maths wrapping bugs. - a version of netpbm-9.24-debiansecurity.patch in netpbm-9.24-10.90.1 is incorrect as it relies on absent properties of mktemp (parallel.c is left "as is"). In the light of the above I propose to use the same sources and patches (i.e. what is provided in netpbm-9.24-9.73.2 plus fixes in attachments to this report) for all distributions from 7.x up to 9 only recompiling in order to link with correct shared libraries and adjusting release designation in specs to reflect that change. As far as I can see nothing else is required. ------- Additional Comments From bugs.michael 2004-06-06 13:10:45 ---- in reply to comment 11, strncpy includes the terminating zero, sizeof doesn't. In attachment 647: | fileName[PATH_MAX - sizeof(mkstempTemplate)] = '\0'; Should read: | fileName[PATH_MAX - sizeof(mkstempTemplate) -1] = '\0'; Because, if getenv really returned something long enough, strcat would store \0 at offset PATH_MAX, which is outside the array. [Hint: Assume PATH_MAX=sizeof(mkstempTemplate)+1] Btw, like attachment 578 [details], with extremely long values returned by getenv, it would create a filename which doesn't make sense, because it overwrites the end with the mkstemp template. Tmp filenames near PATH_MAX are not really expected to work, the precautions with strncpy are just to avoid a buffer overflow. ------- Additional Comments From michal 2004-06-06 13:55:14 ---- > in reply to comment 11, strncpy includes the terminating zero, sizeof doesn't. Err..., no. Try it. #include <stdio.h> int main () { char a[] = "01234"; printf ("%u\n", sizeof(a)); return 0; } Compile and execute. Prints 6 as sizeof() for string constants includes a terminating NULL. OTOH making a maximal path one character too short really does not matter for all practical purposes. We just want to guard against deliberate attempts of buffer overruns. ------- Additional Comments From bugs.michael 2004-06-07 05:32:27 ---- yeah, mixed it up with strlen... ------- Additional Comments From marcdeslauriers 2004-06-11 14:56:29 ---- -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I built packages for 7.3 and 9: - - I used the previous 7.3 rpm to get the bigger security patch - - I used the patches from comments 8 and 13 Changelog: * Fri Jun 11 2004 Marc Deslauriers <marcdeslauriers> 9.24-9.73.3.legacy - - Added security patches for CAN-2003-0924 7.3: c1ec31258953b8cce06425d9f842a7f7623bf05b netpbm-9.24-9.73.3.legacy.i386.rpm 3ca9a4810bdb7de76752b9ecf76f0a3ad45dea64 netpbm-9.24-9.73.3.legacy.src.rpm b327b0cdc675ced2630e0b900e7bb79904794c30 netpbm-devel-9.24-9.73.3.legacy.i386.rpm 0e0d052270065b4d4e5e762c967d5065323da1c8 netpbm-progs-9.24-9.73.3.legacy.i386.rpm 9: 0654f202875f7e3c09b87a778c782928afffd07d netpbm-9.24-10.90.2.legacy.i386.rpm b6afc3b4ca5ae95dac4668d8cb5a528a7a5b174b netpbm-9.24-10.90.2.legacy.src.rpm 78941d6c090307a13e004df5639f9d800957e62f netpbm-devel-9.24-10.90.2.legacy.i386.rpm 0b8384172d1a187fdd2f02a7c7f30053d6dc9c9f netpbm-progs-9.24-10.90.2.legacy.i386.rpm http://www.infostrategique.com/linuxrpms/legacy/7.3/netpbm-9.24-9.73.3.legacy.i386.rpm http://www.infostrategique.com/linuxrpms/legacy/7.3/netpbm-9.24-9.73.3.legacy.src.rpm http://www.infostrategique.com/linuxrpms/legacy/7.3/netpbm-devel-9.24-9.73.3.legacy.i386.rpm http://www.infostrategique.com/linuxrpms/legacy/7.3/netpbm-progs-9.24-9.73.3.legacy.i386.rpm http://www.infostrategique.com/linuxrpms/legacy/9/netpbm-9.24-10.90.2.legacy.i386.rpm http://www.infostrategique.com/linuxrpms/legacy/9/netpbm-9.24-10.90.2.legacy.src.rpm http://www.infostrategique.com/linuxrpms/legacy/9/netpbm-devel-9.24-10.90.2.legacy.i386.rpm http://www.infostrategique.com/linuxrpms/legacy/9/netpbm-progs-9.24-10.90.2.legacy.i386.rpm -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFAylR/LMAs/0C4zNoRAmPlAJ0S+/Yw6vVEgVx/Sjq5Xfu9elfjXQCfUb0w AQM9eMpssGehnv+qld1XJDQ= =pJc+ -----END PGP SIGNATURE----- ------- Additional Comments From jpdalbec 2004-07-28 03:13:11 ---- -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 New RHL 7.3/9 packages are available fixing a missing BuildRequires: flex. sha1sums: 581f1387c1602b49725e79a3ac5834c8003e5457 http://cc.ysu.edu/~jpdalbec/netpbm-9.24-10.90.3.legacy.i386.rpm ac4784a23a85ed45451af06a37f6a1a66f4cd69b http://cc.ysu.edu/~jpdalbec/netpbm-9.24-10.90.3.legacy.src.rpm df1aa67e9cd3c77d986e96b8941fe5b8ca8fd652 http://cc.ysu.edu/~jpdalbec/netpbm-9.24-9.73.4.legacy.i386.rpm 78f3be34f9b08b16b9daed4e9841f4e781d4fbba http://cc.ysu.edu/~jpdalbec/netpbm-9.24-9.73.4.legacy.src.rpm 64b367d8e22c9d9fd5921820706af7253e28b011 http://cc.ysu.edu/~jpdalbec/netpbm-devel-9.24-10.90.3.legacy.i386.rpm b0c95b1d078dbf6e7a72cdbb5e6ccbd10d52ea40 http://cc.ysu.edu/~jpdalbec/netpbm-devel-9.24-9.73.4.legacy.i386.rpm ef02d02cd60d7a962a0b2045dd2151259e688805 http://cc.ysu.edu/~jpdalbec/netpbm-progs-9.24-10.90.3.legacy.i386.rpm 437d2a9bec5354dc334bce8096280a5d2b4c3411 http://cc.ysu.edu/~jpdalbec/netpbm-progs-9.24-9.73.4.legacy.i386.rpm I didn't find any problems with basic testing. (I converted a png file to pnm and then ran pnmmargin on it.) -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQFBB6ZVJL4A+ldA7asRAkgVAKC0y1WeTUlPhPaKec5jgZcdj6paAACaAqno XKVWnOQLvwGx9E66Kz4aXnw= =3mPU -----END PGP SIGNATURE----- ------- Additional Comments From ckelley 2004-09-09 06:38:46 ---- # wget http://cc.ysu.edu/~jpdalbec/netpbm-9.24-9.73.4.legacy.src.rpm --10:38:14-- http://cc.ysu.edu/%7Ejpdalbec/netpbm-9.24-9.73.4.legacy.src.rpm => `netpbm-9.24-9.73.4.legacy.src.rpm' Resolving cc.ysu.edu... done. Connecting to cc.ysu.edu[150.134.10.33]:80... connected. HTTP request sent, awaiting response... 403 Forbidden 10:38:15 ERROR 403: Forbidden. ------- Additional Comments From marcdeslauriers 2004-09-13 14:15:46 ---- John, your packages in comment 21 are not available for download anymore. ------- Additional Comments From jpdalbec 2004-09-14 02:10:52 ---- Fixed, sorry. ------- Additional Comments From ckelley 2004-09-14 09:49:48 ---- -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 78f3be34f9b08b16b9daed4e9841f4e781d4fbba netpbm-9.24-9.73.4.legacy.src.rpm The spec file looks great. The CAN-2003-0924 patch applies cleanly -- it is small and understandable. rpmbuild -ba works flawlessly. PUBLISH -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFBR0tPyQ+yTHz+jJkRAkJrAJwKxHx9t0795hwMws49R9mmYptufQCcCGyg yTyGWAKLsqGqg/gwojeWxic= =J15x -----END PGP SIGNATURE----- ------- Additional Comments From dom 2004-10-03 13:10:11 ---- -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 QA for rh9: ac4784a23a85ed45451af06a37f6a1a66f4cd69b netpbm-9.24-10.90.3.legacy.src.rpm - - SPEC file looks good - - patches look sane - - builds ok PUBLISH -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFBYIa4YzuFKFF44qURAktLAKDd1V5NnnHGF7J9INo0YZGdX9oOXgCeNVnW l7W2IA3f7mHFbJLl9B38zXo= =cNXY -----END PGP SIGNATURE----- ------- Additional Comments From dom 2004-10-03 23:58:50 ---- Pushed to update-testing. http://www.redhat.com/archives/fedora-legacy-list/2004-October/msg00025.html ------- Additional Comments From ckelley 2004-10-06 07:12:32 ---- -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 4a0e11ad855172ce86042d0f85991b6f28f4811b netpbm-9.24-9.73.4.legacy.i386.rpm 79c8c3e9e4ef5c60eb0dd243b38775cb24c49e18 netpbm-9.24-9.73.4.legacy.src.rpm d69d449139408cf50de7557f38fd9f3a3f86b4c3 netpbm-devel-9.24-9.73.4.legacy.i386.rpm 173fa566ed92e222581817c4326b3dd501f24313 netpbm-progs-9.24-9.73.4.legacy.i386.rpm - source package rebuilds fine - binary packages match filecount of rebuilt packages: - binary packages DO NOT match original RPM from redhat; < netpbm-progs-9.24-10.i386.rpm > netpbm-progs-9.24-9.73.4.legacy.i386.rpm < /usr/bin/picttoppm < /usr/share/man/man1/picttoppm.1 - same thing holds with netpbm-progs-9.24-10.90.1.i386.rpm (latest Redhat update) - this is because netpbm-9.24-security.patch removes the file: @@ -36,7 +36,7 @@ PORTBINARIES = 411toppm bmptoppm eyuvtoppm gouldtoppm ilbmtoppm imgtoppm \ leaftoppm mtvtoppm neotoppm \ - pcxtoppm pgmtoppm pi1toppm picttoppm \ + pcxtoppm pgmtoppm pi1toppm \ pjtoppm \ ppm3d ppmbrighten ppmchange ppmcolormask ppmcolors \ ppmdim ppmdist ppmdither \ If that's OK with everyone, then ++VERIFY this release -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFBZCdpyQ+yTHz+jJkRAu8VAJ0QwXCNlyRv/0oPQuqHgX6fSMEADgCgwJ9r DOKOUUvsOVJzTkJtZlN8/QE= =k5ky -----END PGP SIGNATURE----- ------- Additional Comments From sheltren.edu 2004-10-07 05:14:32 ---- -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Verifying packages for RH9: ac5ee4489c0632057ef6d9844ad2c935e5754053 netpbm-9.24-10.90.3.legacy.i386.rpm 0d59209ef7e8e4d7630d8f23c372f01adeddeea5 netpbm-devel-9.24-10.90.3.legacy.i386.rpm 8076a88d1c299a80db24e7559d0ea6853e6520b9 netpbm-progs-9.24-10.90.3.legacy.i386.rpm Signatures & checksums are OK Packages install cleanly Used a few of the binaries from netpbm-progs and they ran fine VERIFY++ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (Darwin) iD8DBQFBZV0VKe7MLJjUbNMRAjYWAJ9LHnJV4aboXT08ystO4io7zN5VdACff9cw 7DW4uMrRnUk0oX0j1Yqnzmw= =Sx3Z -----END PGP SIGNATURE----- ------- Additional Comments From dom 2004-10-07 07:58:54 ---- I will release soon: http://www-astro.physics.ox.ac.uk/~dom/legacy/advisories/1257-netpbm-draft.txt ------- Additional Comments From dom 2004-10-08 01:22:02 ---- Pushed to updates. ------- Bug moved to this database by dkl 2005-03-30 18:23 ------- This bug previously known as bug 1257 at https://bugzilla.fedora.us/ https://bugzilla.fedora.us/show_bug.cgi?id=1257 Originally filed under the Fedora Legacy product and Package request component. Attachments: another version to patch insecure use of temporary files https://bugzilla.fedora.us/attachment.cgi?action=view&id=564 patch for parallel.c https://bugzilla.fedora.us/attachment.cgi?action=view&id=577 patch for parallel.c https://bugzilla.fedora.us/attachment.cgi?action=view&id=578 patch to fix tmpfiles creation in parallel.c https://bugzilla.fedora.us/attachment.cgi?action=view&id=647 Spec file for a fixed netpbm - 7.x distros https://bugzilla.fedora.us/attachment.cgi?action=view&id=652 Unknown priority P2. Setting to default priority "normal". Unknown platform PC. Setting to default platform "All". Setting qa contact to the default for this product. This bug either had no qa contact or an invalid one.