PERL-5.26.1 stack_overflow #16319
Comments
From [email protected]================================================================= SUMMARY: AddressSanitizer: stack-overflow -- |
From [email protected] |
From @hvdsThis reduces to: The same happens for "(", for the same reason. I don't think we class such things as vulnerabilities, can anyone confirm or deny? I'm also not sure what would be involved in avoiding this, or if there's value in doing so. Hugo |
|
The RT System itself - Status changed from 'new' to 'open' |
From [email protected]Hugo van der Sanden via RT wrote:
Confirmed, we don't consider busting the C stack to be a security failure. -zefram |
From @tonycozOn Wed, 10 Jan 2018 18:01:19 -0800, zefram@fysh.org wrote:
Moved to the public queue. Tony |
From @mudongliangDear admin of perlbug, I write this email to confirm whether you have received my perl bug And we need confirmation about this is really a bug to prove the power -- No System Is Safe! |
From @mudongliang---------- Forwarded message ---------- -----BEGIN PGP SIGNED MESSAGE----- The CVE ID is below. Please inform the software maintainer that the
Use CVE-2018-8816. - -- iQIcBAEBCAAGBQJasJlZAAoJEHb/MwWLVhi2LaQP/i4qxjxKiEAcCHt66++qqbtP |
From @tonycozOn Mon, 19 Mar 2018 18:43:35 -0700, mudongliangabcd@gmail.com wrote:
I don't see any tickets with a subject matching "Stack Exhaustion in current perl stable - 3.26.1". I do see ticket 133002, which has subject "Fwd: [scr480305] Perl - 5.26.1" and is from you. From a quick look this doesn't appear to be a security issue. Tony |
|
The RT System itself - Status changed from 'new' to 'open' |
From @mudongliangOn Mon, Mar 26, 2018 at 7:13 PM, Tony Cook via RT <
First, thanks for your response. Second, *Stack Exhaustion* is one kind of memory error vulnerability. At From the log of AddressSanitizer, it is also verified as "Stack Overflow". ASAN:SIGSEGV==27852==ERROR: AddressSanitizer: stack-overflow on address 0x7ffc14cabff8 It should be one security issue. And I could find one CVE( If you have any question about this issue, please let me know.
|
From @iabynOn Mon, Mar 26, 2018 at 07:46:08PM -0400, ��亮 wrote:
If the attacker is able to feed an attacker-specified regex pattern into $_ = "x" x 100; -- |
From [email protected]Maybe you are correct. On Wed, Jan 24, 2018 at 4:09 AM, Tony Cook via RT <perlbug-followup@perl.org
-- |
From @tonycozOn Mon, 26 Mar 2018 22:10:44 -0700, mudongliangabcd@gmail.com wrote:
In the past we haven't treated the same issue as a security issue and we're unlikely to do so in the future. I've (very briefly) discussed ways to mitigate this type of issue with Karl, but I haven't done anything specific on it, and Karl hasn't mentioned anything he's done on it. Tony |
|
The RT System itself - Status changed from 'new' to 'open' |
From [email protected]Hello Perl Product Security Team, *** Please note that this message and any attachments may contain confidential and proprietary material and information and are intended only for the use of the intended recipient(s). If you are not the intended recipient, you are hereby notified that any review, use, disclosure, dissemination, distribution or copying of this message and any attachments is strictly prohibited. If you have received this email in error, please immediately notify the sender and destroy this e-mail and any attachments and all copies, whether electronic or printed. Please also note that any views, opinions, conclusions or commitments expressed in this message are those of the individual sender and do not necessarily reflect the views of Fortinet, Inc., its affiliates, and emails are not binding on Fortinet and only a writing manually signed by Fortinet's General Counsel can be a binding commitment of Fortinet to Fortinet's customers or partners. Thank you. *** |
From [email protected]Vulnerability Notification Dear Perl, The following information pertains to information discovered by Fortinet's As a mature corporation involved in security research, we strive to We look forward to working closely with you to resolve this issue, and If this message is not encrypted, it is because we could not find your key Type of Vulnerability & Repercussions: Affected Product: Upcoming Advisory Reference: Credits: *** Please note that this message and any attachments may contain confidential and proprietary material and information and are intended only for the use of the intended recipient(s). If you are not the intended recipient, you are hereby notified that any review, use, disclosure, dissemination, distribution or copying of this message and any attachments is strictly prohibited. If you have received this email in error, please immediately notify the sender and destroy this e-mail and any attachments and all copies, whether electronic or printed. Please also note that any views, opinions, conclusions or commitments expressed in this message are those of the individual sender and do not necessarily reflect the views of Fortinet, Inc., its affiliates, and emails are not binding on Fortinet and only a writing manually signed by Fortinet's General Counsel can be a binding commitment of Fortinet to Fortinet's customers or partners. Thank you. *** |
From @tonycozOn Thu, May 31, 2018 at 02:24:18PM -0700, secresearch wrote:
This is a stack overflow from parsing a regular expression with deeply /<!--. ?-K\s((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((... This is only exploitable as a denial of service (it crashes perl). We've had this reported to the security list twice before and haven't Tony |
|
The RT System itself - Status changed from 'new' to 'open' |
From @tonycozOn Wed, 04 Apr 2018 17:32:21 -0700, tonyc wrote:
Now public and merging into 132609. Tony |
From @tonycozOn Thu, 31 May 2018 16:22:05 -0700, tonyc wrote:
Also now public and merging into 132609. Tony |
|
There are several different causes merged into this single ticket. The ones from pack remain unfixed. The ones in patterns were fixed by 6ef7fe5 |
As far as I know, people don't tend to accept pack formats from untrusted sources, nor generate hyper-complex formats programmatically. So the value of fixing this is low but not zero: fixing things like this improve our chances of finding real problems by fuzzing, for example. Interestingly, my current system gcc (7.5.0) appears to unroll some levels of the recursion by way of optimization, so I now get: .. and have to go over 500000 to recreate the coredump unless I build with optimization disabled. (This unrolling appears to add about 1K to the size of the executable.) I'm tempted to remove the recursion altogether with a simple counter of at the minor cost that with mismatched parens like |
Now implemented in #19646. I'd be tempted to leave this until after |
I can close this now, @khwilliamson merged the fix in #19646 on 2022-05-28. |
Migrated from rt.perl.org#132609 (status was 'open')
Searchable as RT132609$
The text was updated successfully, but these errors were encountered: