Go Back

Segmentation violation after return from syn_globalhooks_open

I am having an issue where after I return from my implementation of the syn_globalhooks_open subroutine I get a segmentation violation when I haven't attached a Global IO hook to the channel. 

subroutine syn_globalhooks_open
    in channel,	n
    in modes,	OPModes
    in filename,	a

    record
        base_fn,	a25	; Base filename

proc
    ;
    ; OPModes.OPEN_NOLOCK is included in the following:
    ;   OPModes.OPEN_EXCLRW
    ;   OPModes.OPEN_EXCLW
    ;
    if ((int)(modes & OPModes.OPEN_UPDATE) &&
    &	((int)(modes & OPModes.OPEN_INDEXED) ||
    &	(int)(modes & OPModes.OPEN_RELATIVE)) &&
    &	!((int)(modes & OPModes.OPEN_NOLOCK)))
    begin
        ;
        ; Establish I/O hooks on this channel if it is one of the files we want to replicate
        ; (my I/O hooks constructor follows)
        ; add files as needed to the "select" list for them to be tracked 
        ; NOTE: The <StructureName>SqlIO.dbl code needs to be generated as well for the tracking to work
	xcall parse(filename,1,,,,base_fn)	;1 - Don't expand logicals
	using %atrim(base_fn) select
	    ("ADDRESS","ARLNK","BUDGET","CALENDAR","CATAL","CLIENT","COMSYS","CONTAC"),
	    begin
	        new IoHooksISAM(channel,filename,base_fn,"DEFAULT")
	    end
	    ("ARHIST","REBHIST"),
	    begin
	        new IOHooksRELATIVE(channel,filename,base_fn,"DEFAULT")
	    end
	endusing
    end
    xreturn
end

 

4 Answers
1   | Posted by Andrew Meyer to Synergy DBL on 9/2/2020 7:57 PM
Ace Olszowka
Solid; for anyone out in the field this is a great time to front for these features:
  1. Enabling SIG_CORE https://www.synergex.com/docs/#evso/evsoChap1SIGCORE.htm to allow the runtime to actually throw up the segmentation violation to Windows where we can do something about it
  2. (Assuming Windows) Setting up ProcDump https://docs.microsoft.com/en-us/sysinternals/downloads/procdump
    1. This is pretty straight forward, as an administrator open a command prompt and run the following command:
    2. procdump /i /ma
    3. These command will:
      1. /i - Install ProcDump.exe as the Automatic Debugger (https://docs.microsoft.com/en-us/windows/win32/debug/configuring-automatic-debugging#configuring-automatic-debugging-for-application-crashes) in the appropriate registry keys as documented above
      2. /ma - Capture a Heap Dump of this process (this is slightly better than attempting to capture a full memory dump https://support.microsoft.com/en-us/help/254649/overview-of-memory-dump-file-options-for-windows)
Trigger the segmentation fault.

ProcDump will create a dump file with the relevant information next to where it exists, note that these can be quite big depending on the amount of memory allocated by the process (because this is a full heap dump you get everything).

At this point you should have a reasonable amount of information for someone with the source to be able to dig though the code base. There are a few other pieces you will need:
  • You need the EXE/DLL and the PDB of the files affected in the dump
    • In theory Synergex has these, but its best to always make a copy of these as they existed in the environment which triggered the error, this is just in case you have taken a hotfix or some other one off, it speeds up the process.
These files compress very well with zip, and even better with 7zip, compress them before sending them off.

BEWARE these contain the entire contents of the process memory in them, it is very possible that sensitive information is contained within them, try not to post them publicly unless you are OK with having this information leaked (for example the connection information to the SynSQL Service is in there for someone who knows the code base well enough).

Some of this is adapted from this knowledge base article https://resourcecenter.synergex.com/devres/kb-details.aspx?id=1538 (KB Number 100001569 ) which describes how to setup WinDBG to debug this in real time, it is good information and nothing is wrong with it, but most people (especially in a production box) have zero interest in setting up WinDBG or debugging it manually, it is better to capture the dumps and then move on.

9/4/2020 1:59 PM   0  
Andrew Meyer
With further investigation it appears that an open statement where the "mode" is place in quotes seems to trigger the segmentation fault.

i.e.
open (chn=0,"U:I",somefile) ; this causes the segmentation fault right after the xreturn in the syn_globalhooks_open subroutine

changing it to:
open (chn=0,U:I,somefile) ; prevents the segmentation fault from occurring after the xreturn in the syn_globalhooks_open subroutine




 

9/4/2020 2:29 PM   0  
Ace Olszowka
Fascinating, I wonder if this is exploitable? I'll spin up my fuzzer and see what shakes out.

9/4/2020 2:46 PM   0  
Jacklin Garcia
Hi all. Our development team has created tracker 39091 for this issue. I believe the fix is expected in the next release. 

9/8/2020 6:21 PM   0  
Please log in to comment or answer this question.