Opened 19 years ago
Closed 19 years ago
#1799 closed defect (fixed)
Enscript security fixes
Reported by: | Owned by: | Randy McMurchy | |
---|---|---|---|
Priority: | low | Milestone: | 6.2.0 |
Component: | BOOK | Version: | SVN |
Severity: | minor | Keywords: | Enscript |
Cc: |
Description (last modified by ) ¶
Unpatched Enscript is vulnerable to:
CAN-2004-1184: Enscript does not sanitize filenames, which allows remote attackers or local users to execute arbitrary commands via crafted filenames.
CAN-2004-1185: The EPSF pipe support in Enscript allows remote attackers or local users to execute arbitrary commands via shell metacharacters.
CAN-2004-1186: Multiple buffer overflows in Enscript allow remote attackers or local users to cause a denial of service (application crash).
Here "remote attackers" = people who feed untrusted data to Enscript exposed via a web form or a similar mechanism.
Change History (8)
comment:1 by , 19 years ago
Description: | modified (diff) |
---|---|
Keywords: | Enscript added |
Milestone: | future → 6.2 |
Owner: | changed from | to
Priority: | high → highest |
Severity: | normal → blocker |
comment:2 by , 19 years ago
Status: | new → assigned |
---|
comment:3 by , 19 years ago
by , 19 years ago
Attachment: | enscript-1.6.4-security-1.patch added |
---|
comment:4 by , 19 years ago
Resolution: | → invalid |
---|---|
Status: | assigned → closed |
I went in good faith to fix this bug. I figured after looking at the patch it would be a deal where I would apply it, rediff it, and then build and update. 10 minutes at the most.
But instead I get this:
rml@rmlinux: ~/build > cd enscript-1.6.4 rml@rmlinux: ~/build/enscript-1.6.4 > patch -Np1 -i ../enscript.patch patching file src/gsint.h patching file src/main.c Hunk #1 succeeded at 1546 (offset -10 lines). Hunk #2 FAILED at 1569. Hunk #3 FAILED at 1637. 2 out of 3 hunks FAILED -- saving rejects to file src/main.c.rej patching file src/util.c Hunk #3 FAILED at 1905. 1 out of 4 hunks FAILED -- saving rejects to file src/util.c.rej patching file src/psgen.c Hunk #2 succeeded at 2401 with fuzz 1. patching file src/psgen.c
Why bother sending in a patch that doesn't apply? What, is some editor supposed to stop and spend an hour or two to "fix" the patch so that it really works?
It seems as though if someone was concerned enough to send in a patch (and put a bug in the system no less) to fix something, you would think the patch would actually apply. You'd think that they would have actually tested it.
Enscript works fine enough for me (actually I don't use it, but it builds clean). If it has security vulnerabilities, then it must be a different version than we are using in the book, else the patch would apply.
I can only think this patch is for some other version of Enscript and not applicable to BLFS.
Closing the bug as invalid.
comment:5 by , 19 years ago
Resolution: | invalid |
---|---|
Status: | closed → reopened |
Just plain not believing that this bug would be entered without a valid fix, I redownloaded the source and patch and tried to apply again. It applied. I cannot begin to determine what caused the failures before.
Reopening the bug to actually fix it this time.
comment:6 by , 19 years ago
Priority: | highest → low |
---|---|
Severity: | blocker → minor |
Added the patch to the Enscript instructions to fix the security vulnerabilities. The wiki page should probably now be updated to reflect what has been updated in the instructions.
Downgrading the bug, but leaving it open until the wiki page is updated.
comment:7 by , 19 years ago
Resolution: | → fixed |
---|---|
Status: | reopened → closed |
Marking the bug as fixed, because the security patch is in the book.
The setlocale sed in the Wiki is also an important fix, but this is not what this bug is about.
Not sure how to access this patch. Clicking the only link on this ticket page for it doesn't work, and the patch doesn't exist in the LFS repo.