[Oisf-devel] Luajit performance

[Chris Wakelin]

Hi,

I've got a few of Luajit sigs that seem to take rather more ticks than
I'd expect. The first is my XORed binary check (very useful - it spots
SofosFO, the unknown 32-32 hex kit and g01pack payloads), the next two,
by Will Metcalf, are for spotting Flash exploits and the last is one
that Will made for detecting PDFs that exploit a vulnerability in Sophos:

alert http $EXTERNAL_NET any -> $HOME_NET any (msg:"RDG LUAJIT test -
match XORed binary"; flowbits:isset,ET.http.javaclient.vulnerable;
flowbits:isnotset,ET.http.binary; luajit:suri-xor-binary-detect.lua;
flowbits:set,et.exploitkitlanding; classtype:trojan-activity;
sid:379000001; rev:4;)

alert http $EXTERNAL_NET any -> $HOME_NET any (msg:"RDG/ET WEB_CLIENT
Adobe Flash Vuln (CVE-2012-1535 Uncompressed) ";
flow:from_server,established; file_data; content:"FWS"; depth:3;
luajit:CVE-2012-1535.lua; flowbits:set,et.exploitkitlanding;
classtype:trojan-activity; sid:7016688; rev:4;)

alert http $EXTERNAL_NET any -> $HOME_NET any (msg:"RDG/ET WEB_CLIENT
Adobe Flash Vuln (CVE-2012-1535 Compressed)";
flow:from_server,established; file_data; content:"CWS"; depth:3;
luajit:CVE-2012-1535.lua; flowbits:set,et.exploitkitlanding;
classtype:trojan-activity; sid:7016687; rev:4;)

alert http $EXTERNAL_NET any -> $HOME_NET any (msg:"RDG/ET LUAJIT Sophos
PDF Standard Encryption Invalid Key Length Buffer Overflow";
flow:from_server,established; file_data; content:"%PDF-"; depth:5;
content:"/FlateDecode"; luajit:sophos-pdf-exp.lua;
flowbits:set,et.exploitkitlanding; classtype:attempted-user;
sid:6666666; rev:4;)

In theory the Lua should only get run in comparatively rare cases,
namely a PDF download, a Flash file download or a download by a
vulnerable Java client.

However on my test 1GB pcap I get:

>    Num      Rule         Gid      Rev      Ticks        %      Checks   Matches  Max Ticks   Avg Ticks   Avg Match   Avg No Match
>   -------- ------------ -------- -------- ------------ ------ -------- -------- ----------- ----------- ----------- -------------- 
>   1        6666666      1        4        375013957    30.04  1187     0        25052996    315934.25   0.00        315934.25  
>   2        7016687      1        4        169456108    13.57  2095     0        3454659     80885.97    0.00        80885.97   
>   3        2015629      1        4        126068714    10.10  3041     0        804372      41456.33    0.00        41456.33   
>   4        2015654      1        4        124691619    9.99   1361     0        785749      91617.65    0.00        91617.65   
>   5        378000160    1        2        50175909     4.02   178590   0        16186       280.96      0.00        280.96     
>   6        379000001    1        4        33296026     2.67   105155   0        15774       316.64      0.00        316.64     
>   7        2011336      1        4        32077574     2.57   4462     0        21281       7189.06     0.00        7189.06    
>   8        2014956      1        1        27426941     2.20   26101    0        16000       1050.80     0.00        1050.80    
>   9        2015783      1        4        21627250     1.73   12259    0        20194       1764.19     0.00        1764.19    
...
>   50       7016688      1        4        1376700      0.11   249      0        406366      5528.92     0.00        5528.92

I can't see why 7016688 doesn't use as many resources as 7016687 (and as
it happens I'm not actually sure why the two ET sigs, 2015629 and
2015654 are so expensive!)

Any ideas?

Best Wishes,
Chris

-- 
--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+-
Christopher Wakelin,                           c.d.wakelin at reading.ac.uk
IT Services Centre, The University of Reading,  Tel: +44 (0)118 378 2908
Whiteknights, Reading, RG6 6AF, UK              Fax: +44 (0)118 975 3094