Bug 223072

Summary: CVE-2006-6939 Insecure use of temporary file in ed
Product: Red Hat Enterprise Linux 4 Reporter: Lubomir Kundrak <lkundrak>
Component: edAssignee: Karsten Hopp <karsten>
Status: CLOSED DUPLICATE QA Contact:
Severity: low Docs Contact:
Priority: low    
Version: 4.4Keywords: Security
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
URL: http://www.frsirt.com/english/advisories/2006/4573
Whiteboard: impact=low,source=cve,reported=20070117,public=20071111
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2007-01-23 19:14:30 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 223075, 223076    
Attachments:
Description Flags
Backported patch that corrects CVE-2006-6939 GNU ed insecure tmp file handling. none

Description Lubomir Kundrak 2007-01-17 19:34:49 UTC
Description of problem:

Version 0.3 of GNU ed replaced use of unsecure mktemp() followed
by fopen() in buf.c:open_sbuf() with tmpnam(). The former construction
is vulnerable to race condition, where a malicous user can create
the temporary file between two function calls, as they are non-atomic,
and then either read or write the contents of the file, or make it
a symbolic link to a file owned by the victim resulting in its overite.

Version-Release number of selected component (if applicable):

GNU ed 0.2, in RHEL{2.1,3,4,5} and FC{5,6}

How reproducible:

Time-dependent race condition, very unlikely.

Steps to Reproduce:
1. Attempt to guess the filename returned by mktemp() and attempt
create it while being schelduled between mktemp() and fopen() calls.

Comment 1 Lubomir Kundrak 2007-01-17 19:34:49 UTC
Created attachment 145853 [details]
Backported patch that corrects CVE-2006-6939 GNU ed insecure tmp file handling.

Comment 3 Josh Bressers 2007-01-23 19:14:30 UTC
This flaw is really CVE-2000-1137, which we fixed in 2000 via bug 21470.  I'm
marking this bug a dupe.

*** This bug has been marked as a duplicate of 21470 ***