"ls: File too large"

From: Tom Trelvik (tttat_private)
Date: Tue Apr 23 2002 - 13:15:29 PDT

  • Next message: Christopher L Brown: "ATA Protected Area Analysis"

    	So my OpenBSD 2.9 web server was compromised a few days ago (most 
    everything was kept relatively well patched and firewalled if not in use, 
    but we suspect it was probably the PHP-Nuke software (www.phpnuke.org) 
    running on one of the virtual hosts which was exploited, which happened to 
    be the virtual host that was defaced).  It was discovered and shutdown 
    within an hour of the page defacement.  I later booted it up from a cdrom, 
    and prepared to backup the complete filesystems to another machine for 
    later analyzation (by mounting rdonly,noexec,nosuid, of course).
    
    	I was backing up from an OpenBSD 2.9 to a 3.0 system, and was using netcat 
    to do it.  I'd boot the compromised system from a bootable obsd cdrom, 
    which had a statically compiled version of netcat burned onto it as well, 
    select (s)hell, and then run the following:
    
    # dhclient
    # dd if=/dev/wd1a | nc -l <port#>
    
    	And then on my 3.0 system, I'd run
    
    # nc <hostname> <port#> > home.wd1a.fs
    
    	To mount the filesystem, my friend Jose introduced me to a nifty little 
    tool called vnconfig for accessing files via "virtual devices" (because 
    OpenBSD can't do "loopback" mounts, like linux can).  So I'd do the 
    following on the 3.0 system:
    
    # vnconfig -cv svnd0 home.wd1a.fs
    # mount -o rdonly,noexec,nosuid /dev/svnd0c mnt_point/
    # ls -l mnt_point/
    
    	This worked fine on all but one partition, /home.  It would apear to 
    transfer the fs okay via netcat, and I could then use vnconfig, and mount 
    it like I could all the others.  But when I'd try to access it, four of the 
    five home directories gave the following error (the fifth worked normally 
    for whatever reason):
    
    ls: trelvik: File too large
    
    	trelvik was my user name, and so of course was my home directory under 
    /home.  A plain "ls" with no args would list all the home directories 
    normally, but "ls -l" (or most other args) would give that error.  I can't 
    cd into the directories, and judging by bash's attempts at tab completing 
    the names, they don't look like they're being treated as directories (the 
    tab completion adds a space to the end of the name, instead of a slash).  I 
    know that's really nothing conclusive, but I can't get much other 
    information out of them without getting the "File too large" error.
    
    	I thought maybe they'd been corrupted somehow, but I can mount the 
    partition and read them just fine on the original compromised 
    machine.  Trying to transfer the filesystems again gives the same results 
    reliably.
    
    	I was even able to modify my means of transferring the files by just using 
    tar instead of dd, and the 3.0 system could read all the files just fine 
    when I did that.  But I was hoping to have an exact backup of the entire 
    compromised file system rather than just the individual files on it.
    
    	Oh, and just to be sure, the entire /home partition was only 4gig (with 
    1.1gig in use), but one of the other file systems was 8gigs alone, and the 
    3.0 machine had no trouble creating an 8 gig file for that.  So I'm fairly 
    sure this isn't anything related to the actual size of any files, since FFS 
    should easily be able to handle that.
    
    	Any ideas/suggestions??  Anything at all would be greatly appreciated.
    
    Thanks in advance!
    
    Tom
    
    
    -----------------------------------------------------------------
    This list is provided by the SecurityFocus ARIS analyzer service.
    For more information on this free incident handling, management 
    and tracking system please see: http://aris.securityfocus.com
    



    This archive was generated by hypermail 2b30 : Tue Apr 23 2002 - 20:45:12 PDT