Sec Bug->Bug #77569 [Ver]: Write Acess Violation in DomImplementation

From: Date: Wed, 12 Feb 2020 21:04:34 +0000
Subject: Sec Bug->Bug #77569 [Ver]: Write Acess Violation in DomImplementation
References: 1  Groups: php.bugs 
Request: Send a blank email to php-bugs+get-225541@lists.php.net to get a copy of this message
Edit report at https://bugs.php.net/bug.php?id=77569&edit=1 ID: 77569 Updated by: stas@php.net Reported by: christiaanswiersfuture at gmail dot com Summary: Write Acess Violation in DomImplementation Status: Verified -Type: Security +Type: Bug Package: DOM XML related Operating System: Both Windows & Linux PHP Version: master-Git-2019-02-05 (Git) Assigned To: stas Block user comment: N Private report: Y New Comment: I'd commit it to 7.2 out of abundance of caution, but I don't think it needs CVE really because I don't see any plausible scenario how it could be exploited. Previous Comments: ------------------------------------------------------------------------ [2020-02-12 14:50:38] cmb@php.net > But I can't see any plausible scenario how it can happen. Me neither. Anyhow, we need a decision whether this is a security issue or not. If it isn't, it's still a bug, and the fix is trivial. If it is, we should address it as soon as possible. ------------------------------------------------------------------------ [2019-05-15 11:03:11] nikic@php.net @stas: Any decision on how to classify this? The patch is very simple: diff --git a/ext/dom/document.c b/ext/dom/document.c index c9e1802f78..11ef4aa818 100644 --- a/ext/dom/document.c +++ b/ext/dom/document.c @@ -341,7 +341,7 @@ int dom_document_encoding_write(dom_object *obj, zval *newval) str = zval_get_string(newval); - handler = xmlFindCharEncodingHandler(Z_STRVAL_P(newval)); + handler = xmlFindCharEncodingHandler(ZSTR_VAL(str)); if (handler != NULL) { xmlCharEncCloseFunc(handler); ------------------------------------------------------------------------ [2019-03-02 20:53:10] stas@php.net > If the value filled in the encoding is used in a call or jmp statement an attacker may fill in > a memory value to a part in memory that he controls. This can lead to an arbitrary code execution. If the attacker can run the code to set the encoding, he is already executing arbitrary code. The only scenario where this can be a security issue is if the encoding can be set to a non-string value by a legitimate script not written by the attacker. But I can't see any plausible scenario how it can happen. ------------------------------------------------------------------------ [2019-02-15 13:13:07] christiaanswiersfuture at gmail dot com If the value filled in the encoding is used in a call or jmp statement an attacker may fill in a memory value to a part in memory that he controls. This can lead to an arbitrary code execution. So far I have not been able to proof this possible though in this specific situation. ------------------------------------------------------------------------ [2019-02-10 02:15:17] stas@php.net The problem seems to be in this code: 342 str = zval_get_string(newval); 343 344 handler = xmlFindCharEncodingHandler(Z_STRVAL_P(newval)); It converts newval to string, but then for some reason uses un-converted value to call xmlFindCharEncodingHandler. That's definitely wrong. Not sure it's a security issue, unless there's a plausible scenario where DOM encoding is being set from non-string values. I can't see any so far. ------------------------------------------------------------------------ The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=77569 -- Edit this bug report at https://bugs.php.net/bug.php?id=77569&edit=1

« previous php.bugs (#225541) next »