Bug 596501 (CVE-2010-1774)

Summary: CVE-2010-1774 WebKit: out-of-bounds memory access vulnerability in handling of HTML tables
Product: [Other] Security Response Reporter: Vincent Danen <vdanen>
Component: vulnerabilityAssignee: Red Hat Product Security <security-response-team>
Status: CLOSED WONTFIX QA Contact:
Severity: urgent Docs Contact:
Priority: urgent    
Version: unspecifiedCC: bressers, jgrulich, jlieskov, jreznik, security-response-team, stransky, than
Target Milestone: ---Keywords: Security
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2015-08-05 08:18:35 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: 806808    

Description Vincent Danen 2010-05-26 20:19:06 UTC 
An out of bounds memory access issue issue exists in WebKit's handling of HTML tables. Visiting a maliciously crafted website may lead to an unexpected application termination or arbitrary code execution. This issue is addressed through improved bounds checking.

References:

Bugzilla: https://bugs.webkit.org/show_bug.cgi?id=38261
Trac: http://trac.webkit.org/changeset/59495

Acknowledgements:

Red Hat would like to thank Drew Yao of Apple Product Security for responsibly reporting this issue. Upstream acknowledges wushi of team509 as the original reporter.
Comment 4 Josh Bressers 2010-06-04 16:04:02 UTC 
This is likely a crash only, but it seems it doesn't affect RHEL5 or RHEL6.

This snipped appears to save the day:

            if( cCol + i >= nEffCols ) {
            table->appendColumn( span - usedSpan );
            nEffCols++;
            width.resize( nEffCols );
            width[nEffCols-1] = Length();
            }

As the value of i increases, so does the size of width. This should mean that the worst outcome of this flaw would be an OOB read, not an OOB write. An OOB read is a DoS only and not security for end user applications.

It someone sees a flaw in my analysis, please speak up.
Comment 5 Vincent Danen 2010-06-04 16:10:04 UTC 
The same code above exists in KDE4's KHTML as well (khtml/rendering/table_layout.cpp) so would not affect KDE3 or KDE4.
Comment 6 Jan Lieskovsky 2010-06-08 16:57:13 UTC 
Public via:
  [1] http://support.apple.com/kb/HT4196