Slashdot Mirror

← Back to Domains

Domain: core-sdi.com

Stories and comments across the archive that link to core-sdi.com.

Comments · 6

  1. Re:So simple, we might as well do it. by steveha · · Score: 2, Informative · on Transmeta To Add 'NX' Antivirus Feature To Chips

    Here's an even better tutorial on how to do buffer overrun attacks:

    http://community.core-sdi.com/~juliano/exploit_tut orial.txt

    steveha

  2. Re:So simple, we might as well do it. by steveha · · Score: 4, Insightful · on Transmeta To Add 'NX' Antivirus Feature To Chips
    A buffer overrun is a way of putting data PAST the end of your variable (which would be marked NX in your hypothetical scenario) into an about-to-be-executed chunk memory.

    That could be true, if the buffer were placed right before an executable chunk. But it never is. Variables are allocated on the stack, not in code space. Heap memory is often allocated near the stack, but again not in code space.

    When a program calls a function, it stashes a return address on the stack. This address specifies where execution should resume after the function returns. If an exploit can overrun the stack, the exploit overruns this return address! So an exploit will fill a buffer, run off the end of the buffer, put an address on the stack right where it overwrites the return address of the current function, and possibly then overrun some more. If there is a function embedded in the overrun (either on top of the buffer, or after the return address) the address of that function is used to overwrite the return address. So when the function returns, that function runs. A small amount of code can act as a bootstrap loader that loads the rest of the exploit.

    Here's a primer on how to write a basic stack smashing local root attack. I just found this with Google.

    http://community.core-sdi.com/~juliano/htce.txt

    Here's the text of a comment from the sample code:

    filling up the end of the buffer with our shellcode which will be executed on the stack after the bof

    Emphasis added by me. "executed on the stack"... in other words, this exploit would not work if the stack were marked NX, like I said.

    Can you find me an article about how to execute a stack-smashing attack, where the exploit actually blows past the end of the stack or the heap and somehow winds up in normal code space? I have never heard of any such. Can you find even one example of the technique as you describe it?

    steveha
  3. Core-SDI by cHALiTO · · Score: 1 · on Recommendations for Third Party Security Audits?

    I recommend Core SDI.

    Those people really know what they're doing.

  4. New class of vulnerabilities? Bah, humbug by John+Marshall · · Score: 2 · on Various *nix OSes Open To Format String Attacks
    From Core SDI's advisory:
    printf(gettext("usage: %s filename\n"),argv[0]);
    [...]
    Here the output of the gettext(3) function is not validated and passed directly to printf(3).
    Sounds worrying (and we've known about such problems for ages), but
    A malicious, unprivileged, user can build and install a bogus messages database and instruct the vulnerable program to use it, thus controlling the output of gettext() and force-feeding formatting characters to printf(3).
    Surely the real vulnerability here is that the environment has been set up such that an unprivileged user can instruct a setuid program to use an arbitrary unvetted control file?
  5. THERE IS A BUFFER OVERFLOW! by Alejo · · Score: 2 · on Microsoft IIS4 Backdoor Claim Retracted
    Why all talk WITHOUT checking?

    Facts:

    1. IIS w/ option pack HAS a "backdoor" with "netscapeengeniersareweenies" (or something like that).
      • It allows every user with access to read all other user's .asp files. This seems not to be a bug!
      • I HAVE SEEN IT WORK.
      • So as it is would affect mostly web-hosting companies
    2. BUT, Core-SDI's Gera and Beto have found a buffer overflow vulnerability.
      • It lets ANYBODY on the internet to crash a IIS with mentioned option pack (called a DOS).
      • It is demonstrated using a perl script posted on BUGTRAQ.
      • It seems HIGLY POSSIBLE to use THIS buffer overflow for arbitrary remote code execution.
      • I HAVE SEEN IT WORK.
      • So as it is affect ALL IIS w/ option pack4 on the net!!!
    Notes:
    • I work too at Core-SDI.
    • I hate lewsers talking without even trying it.
    • I hate how SLASHDOT just becomes vaporware-information.
    • This are the same guys who spotted RSALIB's overflows last year!
    • For god's sake, even M$ admitted it!!!!
  6. Anti-Cert (Very Stupid People) by RetroCool · · Score: 1 · on CERT Advisory On Malicious HTML Tags

    Cert is the most stupid place in the earth!!!
    Have you cert a moderator inside you???
    This topic is very old, and everybody in the computer security community knows about it
    Why put an advisory?
    You guys, don't have anymore to say about security?
    I don't know if somebody from cert is sending these advisories to slashdot, but in the previous case, somebody sent an advisory for the problem with rsaref (buffer overflow) , but Core SDI discovered this bug
    And I think, again, this was not a clean news.