The Spanner logo
    • Home
    • Blog
      • Blog home
      • RSS
    • Login
    • Home
    • Blog
      • Blog home
      • RSS
    • Login
    The Spanner logo

    The Spanner
    Web security blog

    Made by Gareth Heyes
    Follow me on Twitter: @garethheyes

    Javascript for hackers!

    Hackvertor logo
    Shazzer logo
    My Github account
    Recent posts
    Introducing Feedworm: A Privacy-First RSS Reader That Lives in DevToolsSpeedy RSVP extensionAutoVaderHackvertor history and tag finderShadow Repeater v1.2.3 releaseBurp Hackvertor v2.1.24 releaseHacking roomsXSSing TypeErrors in SafarivalueOf: Another way to get thisMaking the Unexploitable Exploitable with X-Mixed-Replace on FirefoxThe curious case of the evt parameterCSS-Only Tic Tac Toe ChallengeRewriting relative urls with the base tag in SafariBypassing DOMPurify with mXSSNew IE mutation vectorHow I smashed MentalJSMentalJS DOM bypassAnother XSS auditor bypassXSS Auditor bypassBypassing the IE XSS filterUnbreakable filterMentalJS bypassesmXSSJava SerializationBypassing the XSS filter using function reassignmentRPOSandboxed jQueryX-Domain scroll detection on IE using focusEpic fail IEnew operatorDecoding complex non-alphanumeric JavaScriptHacking FirefoxDOM ClobberingBypassing XSS AuditorThe evolution of codeNon-Alpha PHP in 6-7 charsetTweetable PHP-Non AlphaMentalJS for PHPOpera x domain with video tutorialSandboxing and parsing jQuery in 100ms

    new operator

    By Gareth Heyes (@hackvertor)

    Published 12 years 6 months ago • Last updated March 22, 2025 • ⏱️ < 1 min read

    ← Back to articles

    I was playing around with new operators when I noticed something cool and unexpected. If you return a function the new operator will not create a new object instance but instead return a function. This means that stuff like:

    new new new new new new function f(){return f}

    Is perfectly valid code. That made me think maybe it would cause a crash. Yep course it does on IE: eval(Array(0xffff).join('new ')+'function f(){return f}')

    ModLoad: 0000000070af0000 0000000070ba5000 C:\Windows\SysWOW64\MsSpellCheckingFacility.dll ModLoad: 0000000069a40000 0000000069a8f000 C:\Windows\SysWOW64\Bcp47Langs.dll ModLoad: 0000000074cd0000 0000000074cd3000 C:\WINDOWS\SysWOW64\Normaliz.dll (1778.173c): C++ EH exception - code e06d7363 (first chance) (1778.173c): Stack overflow - code c00000fd (first chance) First chance exceptions are reported before any exception handling. This exception may be expected and handled. JSCRIPT9!Scanner<NullTerminatedUTF8EncodingPolicy>::Scan+0x8: 70e69742 53 push ebx

    Just a stack overflow, I don't think it's exploitable but lets try and manipulate it further. Using unicode escapes changes the code slightly:

    eval(Array(0xffff).join('\\u006e\u0065w ')+'function f(){return f}')

    msvcrt!memcmp+0xc: 7506985c 56 push esi

    I then thought about using different types of spaces and fuzzed them but had no success producing any form of exploitable crash, maybe you can?

    ← Back to articles