full-disclosure - Trend Micro has problems with their activeupdate server

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: <12180965.1079615806@[10.3.62.6]>
From: pbieringer at aerasec.de (Dr. Peter Bieringer)
Subject: Trend Micro has problems with their activeupdate server

Hi,

sure interesting for administrators of Trend Micro Interscan Viruswall or 
IMSS.

In general, pattern update server should be very reliable, especially in 
case of need for pattern updates because of a new worm is spreading...

Since longer we have problem on a customers installation with reliability 
of the pattern update process.

E.g. on Interscan Virus Wall Linux 3.8 "prescan.cgi" (triggered by cron) 
reports "error 28".
This error is caused by a missing file on the Akamai servers (TM is using 
them for distributing updates):

http://isux-t.activeupdate.trendmicro.com/activeupdate/server.ini
sometimes returns: HTTP/1.0 404 Not Found

BTW: another administrator (using IMSS) reports me that HTTP error 500, 502 
and 504 also occurs sometimes.

isux-t.activeupdate.trendmicro.com is directed to an Akamai server:

isux-t.activeupdate.trendmicro.com. 496 IN CNAME 
trendmicro.georedirector.akadns.net.

BTW: for ISVW, if you want to retrieve information, why your update process 
fails, enable debugging:

  1. Edit aucfg.ini
  2. Look for [debug] then set the following parameters
      level=1
      log_mode=2

Debug file /etc/iscan/Au_log/tmudump.txt contain the full HTTP header lines
of request and reply.

After a long time of discussion with the support of TM (they longer wanted 
to convince me that the problem is on client side...I didn't believed that 
after I looked in the debug log for the first time), I finally got a *clear 
answer* from Trend Micro support, in short they told me, it can happen that 
an update fails with HTTP error 404 (sure, the debug log tells this 
also...).

Support told me also that this can happen if many new patterns are 
published in short time range, which overloads (?) the activeupdate server.

Mho: Either Akamai has a synchronisation problem here (does anybody know 
how they sync) or TM delete the file, Akamai syncs (which removes the file 
temporary), TM pushes the file again, Akamai syncs again.

Support told me also, as a workaround I should reduce the cycles for 
pattern check to e.g. each 10 minutes (easy to do by modifiying the crontab 
entry).

Mho: if everyone does this, the pattern server will have next problems, 
namely request overloads...

Looks like this problem can't be really solved shortly by TM, so users of 
at least the Linux/Unix products of Trend Micro running pattern update 
cycles per server have to live with this issue for now.

Any comments or same experience on that issue by anyone else?

BTW: common known is update server overload problems to full hour times 
(many Unix/Linux boxes are synced via NTP), any admin should replace "0" in 
crontab by a "random" value between "1" and "59" for process "prescan.cgi".

File "/var/spool/cron/root"
eg.
11 * * * * /etc/iscan/prescan.cgi
instead of
0 * * * * /etc/iscan/prescan.cgi

	Peter
-- 
Dr. Peter Bieringer                             Phone: +49-8102-895190
AERAsec Network Services and Security GmbH        Fax: +49-8102-895199
Wagenberger Stra?e 1                           Mobile: +49-174-9015046
D-85662 Hohenbrunn                       E-Mail: pbieringer@...asec.de
Germany                                Internet: http://www.aerasec.de