Linux security vs Windows with A/V software and firewall. - Linux

This is a discussion on Linux security vs Windows with A/V software and firewall. - Linux ; On Mon, 21 Jan 2008 17:11:50 +0000, AZ Nomad wrote: > Not only that, but without going after system files, worms and virii are > nearly impossible. What do you mean by "without going after system files..."? > In a ...

+ Reply to Thread
Page 3 of 4 FirstFirst 1 2 3 4 LastLast
Results 41 to 60 of 66

Thread: Linux security vs Windows with A/V software and firewall.

  1. Re: Linux security vs Windows with A/V software and firewall.

    On Mon, 21 Jan 2008 17:11:50 +0000, AZ Nomad wrote:


    > Not only that, but without going after system files, worms and virii are
    > nearly impossible.


    What do you mean by "without going after system files..."?

    > In a sane system, email messages are only documents. They can't infect
    > a system; they can't open the address book and resend themselves. They
    > can't do a damn thing on their own.



    I have to admit that I don't understand these holes. Outlook downloads
    the text file, which has some HTML and perhaps a JPG attached. Outlook
    then, through HTTP, grabs, perhaps, a JPG. In either case the JPG file
    is opened. Opening JPG launches the virus (which is attached to the JPG)?


    -Thufir

  2. Re: Linux security vs Windows with A/V software and firewall.

    On Tue, 22 Jan 2008 01:21:35 GMT, Thufir wrote:
    >On Mon, 21 Jan 2008 17:11:50 +0000, AZ Nomad wrote:



    >> Not only that, but without going after system files, worms and virii are
    >> nearly impossible.


    >What do you mean by "without going after system files..."?

    which word don't you understand?

    If you don't overwrite the operating system, you can't install a virus.



    >> In a sane system, email messages are only documents. They can't infect
    >> a system; they can't open the address book and resend themselves. They
    >> can't do a damn thing on their own.



    >I have to admit that I don't understand these holes. Outlook downloads
    >the text file, which has some HTML and perhaps a JPG attached. Outlook
    >then, through HTTP, grabs, perhaps, a JPG. In either case the JPG file
    >is opened. Opening JPG launches the virus (which is attached to the JPG)?


    Why the **** should a JPG execute code? It's just a graphical
    image format. Read the data; decompress it; put the image in a window.


    Only on a windows system would viewing a picture be a dangerous operation.

  3. Re: Linux security vs Windows with A/V software and firewall.

    AZ Nomad wrote:
    > which word don't you understand?
    >
    > If you don't overwrite the operating system, you can't install a virus.


    I've seen a few exploits that only stayed active in RAM, never
    overwrote any system files, and thus were cleared with a reboot.
    Some web browser exploits are like that. Of course those can't
    spread themselves as easily and thus are not as common. In
    fact I am not sure how they replicate/propogate, so I am not
    sure they really qualify as a virus.

    > Why the **** should a JPG execute code? It's just a graphical
    > image format. Read the data; decompress it; put the image in a window.


    That sounds to me like a buffer overflow. You put some bad data in
    an image header or meta tags, cause the image library to run past
    a buffer boundary and smash the stack, tuck your exploit code in
    image data, and you're off to the races.

    It is frighteningly easy actually, when you know what you are doing.

    Moral of the story: bounds check your buffers and arrays.

    Thad
    --
    Yeah, I drank the Open Source cool-aid... Unlike the other brand, it had
    all the ingredients on the label.

  4. Re: Linux security vs Windows with A/V software and firewall.

    On Mon, 21 Jan 2008 21:04:56 -0600, thad05@tux.glaci.delete-this.com wrote:
    >AZ Nomad wrote:
    >> which word don't you understand?
    >>
    >> If you don't overwrite the operating system, you can't install a virus.


    >I've seen a few exploits that only stayed active in RAM, never
    >overwrote any system files, and thus were cleared with a reboot.
    >Some web browser exploits are like that. Of course those can't
    >spread themselves as easily and thus are not as common. In
    >fact I am not sure how they replicate/propogate, so I am not
    >sure they really qualify as a virus.


    >> Why the **** should a JPG execute code? It's just a graphical
    >> image format. Read the data; decompress it; put the image in a window.


    >That sounds to me like a buffer overflow. You put some bad data in
    >an image header or meta tags, cause the image library to run past
    >a buffer boundary and smash the stack, tuck your exploit code in
    >image data, and you're off to the races.


    >It is frighteningly easy actually, when you know what you are doing.


    >Moral of the story: bounds check your buffers and arrays.


    and don't do it as root/admin.

  5. Re: Linux security vs Windows with A/V software and firewall.

    On Tue, 22 Jan 2008 01:50:59 +0000, AZ Nomad wrote:

    > On Tue, 22 Jan 2008 01:21:35 GMT, Thufir wrote:
    >>On Mon, 21 Jan 2008 17:11:50 +0000, AZ Nomad wrote:

    >
    >
    >>> Not only that, but without going after system files, worms and virii
    >>> are nearly impossible.

    >
    >>What do you mean by "without going after system files..."?

    > which word don't you understand?


    It's the grammar I don't follow. The worm and virii "go
    after" (currupt?) system files (DLL's?).

    > If you don't overwrite the operating system, you can't install a virus.


    Meaning replace one DLL with another?

    [...]
    > Why the **** should a JPG execute code? It's just a graphical image
    > format. Read the data; decompress it; put the image in a window.


    Ok.

    > Only on a windows system would viewing a picture be a dangerous
    > operation.




    -Thufir

  6. Re: Linux security vs Windows with A/V software and firewall.

    Thufir wrote:
    > On Tue, 22 Jan 2008 01:50:59 +0000, AZ Nomad wrote:
    >
    >> On Tue, 22 Jan 2008 01:21:35 GMT, Thufir wrote:
    >>> On Mon, 21 Jan 2008 17:11:50 +0000, AZ Nomad wrote:

    >>
    >>>> Not only that, but without going after system files, worms and virii
    >>>> are nearly impossible.
    >>> What do you mean by "without going after system files..."?

    >> which word don't you understand?

    >
    > It's the grammar I don't follow. The worm and virii "go
    > after" (currupt?) system files (DLL's?).


    A DLL is not a system file. A DLL is a Dynamic Link Library. You cannot
    corrupt a DLL. You can replace a DLL with another DLL that has dubious
    intent. But most of the time a worm or virus comes as its own standalone
    process or it will seek a host like Svchost.exe or Dllhost.exe or other
    such exe(s) that act as the host for a DLL.

    >
    >> If you don't overwrite the operating system, you can't install a virus.

    >
    > Meaning replace one DLL with another?


    Gee, you got that right but what happens is that a payload is dropped,
    it's not overwriting any thing. It is so disguised or named that it
    can't be detected, easily.


    There are several tools that can help anyone that knows how to use them,
    and they can look for them self from time to time. But that also
    involves that the person sitting behind the wheel has some type of
    knowledge of the O/S.



    Security is a process and it's not a given, like practicing safe hex. It
    doesn't matter what O/S it being used. One puts the computer at risk
    with reckless behavior, then the machine can get compromised. And it
    doesn't matter what O/S is being used.

    In addition, on any given O/S platform, if a machine gets compromised,
    which this is particularly true for the home user sector, then 99.9% of
    the time, the end-user had involvement in it in someway. It just doesn't
    happen by it self.

  7. Re: Linux security vs Windows with A/V software and firewall.

    Cross Posting HO wrote:

    > Thufir wrote:
    >> On Tue, 22 Jan 2008 01:50:59 +0000, AZ Nomad wrote:
    >>
    >>> On Tue, 22 Jan 2008 01:21:35 GMT, Thufir wrote:
    >>>> On Mon, 21 Jan 2008 17:11:50 +0000, AZ Nomad wrote:
    >>>
    >>>>> Not only that, but without going after system files, worms and virii
    >>>>> are nearly impossible.
    >>>> What do you mean by "without going after system files..."?
    >>> which word don't you understand?

    >>
    >> It's the grammar I don't follow. The worm and virii "go
    >> after" (currupt?) system files (DLL's?).

    >
    > A DLL is not a system file. A DLL is a Dynamic Link Library. You cannot
    > corrupt a DLL.


    Sure you can. What would hinder a virus to overwrite part of the DLL and/or
    append itself to it?

    > You can replace a DLL with another DLL that has dubious intent.


    Naturally another possiility. But just another one, not the only one

    < snip >

    >> Meaning replace one DLL with another?

    >
    > Gee, you got that right but what happens is that a payload is dropped,
    > it's not overwriting any thing.


    Bull****

    > It is so disguised or named that it can't be detected, easily.


    Really?

    < snip more stuff "linux_sux" knows nothing about >
    --
    You're not my type. For that matter, you're not even my species


  8. Re: Linux security vs Windows with A/V software and firewall.

    Peter Köhlmann wrote:
    > Cross Posting HO wrote:
    >
    >> Thufir wrote:
    >>> On Tue, 22 Jan 2008 01:50:59 +0000, AZ Nomad wrote:
    >>>
    >>>> On Tue, 22 Jan 2008 01:21:35 GMT, Thufir wrote:
    >>>>> On Mon, 21 Jan 2008 17:11:50 +0000, AZ Nomad wrote:
    >>>>>> Not only that, but without going after system files, worms and virii
    >>>>>> are nearly impossible.
    >>>>> What do you mean by "without going after system files..."?
    >>>> which word don't you understand?
    >>> It's the grammar I don't follow. The worm and virii "go
    >>> after" (currupt?) system files (DLL's?).

    >> A DLL is not a system file. A DLL is a Dynamic Link Library. You cannot
    >> corrupt a DLL.

    >
    > Sure you can. What would hinder a virus to overwrite part of the DLL and/or
    > append itself to it?


    Comon man, the application that was using the DLL legitimately would
    start to blow up, and it would be a sure sign of trouble. But that would
    take for you to know something about OOp(s) programming.
    >
    >> You can replace a DLL with another DLL that has dubious intent.

    >
    > Naturally another possiility. But just another one, not the only one


    But that's the majority of the time.
    >
    > < snip >
    >
    >>> Meaning replace one DLL with another?

    >> Gee, you got that right but what happens is that a payload is dropped,
    >> it's not overwriting any thing.

    >
    > Bull****


    What man? Do think that a worm or virus cannot drop a payload to be
    executed once the user points and clicks, a standalone or self contained
    virus? What kind of nonsense are you talking about here?

    Jesus, you're just a dumbass home user. And it doesn't matter what
    platform you are using or not using.
    >
    >> It is so disguised or named that it can't be detected, easily.

    >
    > Really?
    >


    Yeah really, like SVchots.exe that not running out of the System32
    directory or Dllhost.exe not running out of System32, and the user sees
    them running. That's a sure sign they are Trojans, and the end-user
    doesn't know it. They are not aware of it. And most like you are too
    stupid to realize what is going on.

    > < snip more stuff "linux_sux" knows nothing about >


    Who cares? The OP had the word Windows on his breath.

    Anyway, I got to get to work making that $,$$$$ every working day doing
    ..Net programming. I got to pay those bills.



  9. Re: Linux security vs Windows with A/V software and firewall.

    Cross Posting HO wrote:

    > Peter Köhlmann wrote:
    >> Cross Posting HO wrote:
    >>
    >>> Thufir wrote:
    >>>> On Tue, 22 Jan 2008 01:50:59 +0000, AZ Nomad wrote:
    >>>>
    >>>>> On Tue, 22 Jan 2008 01:21:35 GMT, Thufir
    >>>>> wrote:
    >>>>>> On Mon, 21 Jan 2008 17:11:50 +0000, AZ Nomad wrote:
    >>>>>>> Not only that, but without going after system files, worms and virii
    >>>>>>> are nearly impossible.
    >>>>>> What do you mean by "without going after system files..."?
    >>>>> which word don't you understand?
    >>>> It's the grammar I don't follow. The worm and virii "go
    >>>> after" (currupt?) system files (DLL's?).
    >>> A DLL is not a system file. A DLL is a Dynamic Link Library. You cannot
    >>> corrupt a DLL.

    >>
    >> Sure you can. What would hinder a virus to overwrite part of the DLL
    >> and/or append itself to it?

    >
    > Comon man, the application that was using the DLL legitimately would
    > start to blow up, and it would be a sure sign of trouble. But that would
    > take for you to know something about OOp(s) programming.


    Bull****.
    The malware need only read the DLL entry point, attach itself to the DLL and
    overwrite the entry, pointing to itself and after it has initialized,
    continue at the original entry point

    Nothing blows up, you incompetent nincompwit

    If you start to learn the first tiny shred about programming, come back to
    us. As of now, just refrain from showing your total incompetence

    >
    >>> You can replace a DLL with another DLL that has dubious intent.

    >>
    >> Naturally another possiility. But just another one, not the only one

    >
    > But that's the majority of the time.


    How would you know? You don't even know how easy it is to overwrite DLLs
    with malware

    Hint, you typical clueless wintendo luser: It is practically the same
    procedure as with EXE files

    >> < snip >
    >>
    >>>> Meaning replace one DLL with another?
    >>> Gee, you got that right but what happens is that a payload is dropped,
    >>> it's not overwriting any thing.

    >>
    >> Bull****

    >
    > What man? Do think that a worm or virus cannot drop a payload to be
    > executed once the user points and clicks, a standalone or self contained
    > virus? What kind of nonsense are you talking about here?


    No. Your assertion that "nothing is overwritten"
    Complete, utterly clueless dribble

    > Jesus, you're just a dumbass home user. And it doesn't matter what
    > platform you are using or not using.


    Talk about yourself much lately?

    < snip more lies from "linux_sux" >

    --
    Windows: Because everyone needs a good laugh!


  10. Re: Linux security vs Windows with A/V software and firewall.

    Peter Köhlmann wrote:
    > Cross Posting HO wrote:
    >
    >> Peter Köhlmann wrote:
    >>> Cross Posting HO wrote:
    >>>
    >>>> Thufir wrote:
    >>>>> On Tue, 22 Jan 2008 01:50:59 +0000, AZ Nomad wrote:
    >>>>>
    >>>>>> On Tue, 22 Jan 2008 01:21:35 GMT, Thufir
    >>>>>> wrote:
    >>>>>>> On Mon, 21 Jan 2008 17:11:50 +0000, AZ Nomad wrote:
    >>>>>>>> Not only that, but without going after system files, worms and virii
    >>>>>>>> are nearly impossible.
    >>>>>>> What do you mean by "without going after system files..."?
    >>>>>> which word don't you understand?
    >>>>> It's the grammar I don't follow. The worm and virii "go
    >>>>> after" (currupt?) system files (DLL's?).
    >>>> A DLL is not a system file. A DLL is a Dynamic Link Library. You cannot
    >>>> corrupt a DLL.
    >>> Sure you can. What would hinder a virus to overwrite part of the DLL
    >>> and/or append itself to it?

    >> Comon man, the application that was using the DLL legitimately would
    >> start to blow up, and it would be a sure sign of trouble. But that would
    >> take for you to know something about OOp(s) programming.

    >
    > Bull****.
    > The malware need only read the DLL entry point, attach itself to the DLL and
    > overwrite the entry, pointing to itself and after it has initialized,
    > continue at the original entry point
    >
    > Nothing blows up, you incompetent nincompwit
    >
    > If you start to learn the first tiny shred about programming, come back to
    > us. As of now, just refrain from showing your total incompetence
    >
    >>>> You can replace a DLL with another DLL that has dubious intent.
    >>> Naturally another possiility. But just another one, not the only one

    >> But that's the majority of the time.

    >
    > How would you know? You don't even know how easy it is to overwrite DLLs
    > with malware
    >
    > Hint, you typical clueless wintendo luser: It is practically the same
    > procedure as with EXE files


    You dumbass clown, do you NOT know about the contract and the interfaces
    that a legit exe or client would be expecting when consuming the DLL
    (the client) that was the legitimate user of the DLL the (server)?

    Eventually, the compormise would be exposed -- Superman Linux user -- not.


    >
    >>> < snip >
    >>>
    >>>>> Meaning replace one DLL with another?
    >>>> Gee, you got that right but what happens is that a payload is dropped,
    >>>> it's not overwriting any thing.
    >>> Bull****

    >> What man? Do think that a worm or virus cannot drop a payload to be
    >> executed once the user points and clicks, a standalone or self contained
    >> virus? What kind of nonsense are you talking about here?

    >
    > No. Your assertion that "nothing is overwritten"
    > Complete, utterly clueless dribble


    And ditto on your nonsens too.

    >
    >> Jesus, you're just a dumbass home user. And it doesn't matter what
    >> platform you are using or not using.

    >
    > Talk about yourself much lately?


    ditto - Superman, not -- and not a god to the computer industry.


    >
    > < snip more lies from "linux_sux" >
    >


    WTF are you talking about above?

  11. Re: Linux security vs Windows with A/V software and firewall.

    Peter Köhlmann wrote:

    >
    > Hint, you typical clueless wintendo luser: It is practically the same
    > procedure as with EXE files
    >



    And you see, that's the problem with people that use Linux, and why
    Linux will never appeal to the mases it will never happen, which is your
    ****ed-up take on things and people like you.

    Because once they step in to a NG such as this to start asking
    questions, people like you will try to decapitate them.

    You're ****ed-up and this NG is ****ed-up.

  12. Re: Linux security vs Windows with A/V software and firewall.

    Cross Posting HO wrote:

    > Peter Köhlmann wrote:
    >
    >>
    >> Hint, you typical clueless wintendo luser: It is practically the same
    >> procedure as with EXE files
    >>

    >
    >
    > And you see, that's the problem with people that use Linux, and why
    > Linux will never appeal to the mases it will never happen, which is your
    > ****ed-up take on things and people like you.
    >
    > Because once they step in to a NG such as this to start asking
    > questions, people like you will try to decapitate them.
    >
    > You're ****ed-up and this NG is ****ed-up.


    Translation: You got your ass handed, and can't cope with the situation.

    You have to be shown to be utterly incompetent, and that while you where
    claiming to earn your living with the exact stuff you obviously know
    nothing about.

    It must suck to be you
    --
    I refuse to have a battle of wits with an unarmed person.


  13. Re: Linux security vs Windows with A/V software and firewall.

    In comp.os.linux.advocacy, Cross Posting HO

    wrote
    on Tue, 22 Jan 2008 08:14:33 -0500
    <13pbr1qijblqv8a@corp.supernews.com>:
    > Thufir wrote:
    >> On Tue, 22 Jan 2008 01:50:59 +0000, AZ Nomad wrote:
    >>
    >>> On Tue, 22 Jan 2008 01:21:35 GMT, Thufir wrote:
    >>>> On Mon, 21 Jan 2008 17:11:50 +0000, AZ Nomad wrote:
    >>>
    >>>>> Not only that, but without going after system files, worms and virii
    >>>>> are nearly impossible.
    >>>> What do you mean by "without going after system files..."?
    >>> which word don't you understand?

    >>
    >> It's the grammar I don't follow. The worm and virii "go
    >> after" (currupt?) system files (DLL's?).

    >
    > A DLL is not a system file. A DLL is a Dynamic Link Library. You cannot
    > corrupt a DLL. You can replace a DLL with another DLL that has dubious
    > intent. But most of the time a worm or virus comes as its own standalone
    > process or it will seek a host like Svchost.exe or Dllhost.exe or other
    > such exe(s) that act as the host for a DLL.


    I'll admit to wondering about that. A DLL could easily
    be modified, if one has write access (and no one's using
    the inode; this is a quirk Linux to some extent shares
    with Windows, though in Linux it's far less visible).
    Of course with Linux only root has write access to most
    of the system DLLs, though one can modify things so that
    bin is the owner and no one has write access, or /usr is
    mounted read-only, or /bin and /sbin are in the initialboot
    RAM drive, etc., with sufficiently clever boot scripts.

    (In a Windows system, things get a little sloppy on most
    installations.)

    It does not appear all that difficult to add a section to
    the DLL with some dangerous position-independent code,
    and modify Elf32_Ehdr.e_entry (see /usr/include/elf.h).
    Upon initial load the virus gains control. He would
    probably want to add his section to other surrounding DLLs
    (if they're not already affected), and then proceed to the
    original e_entry, which he's carefully preserved someplace.

    The user might notice a little additional disk activity.

    Since DLLs are read-only if in use (ETXTBSY), the virus
    writer would probably have to have write access to /bin
    as well, to allow rename() to work. A temporary scratch
    area is also indicated (/tmp or /var/tmp). Once the new
    DLL is ready it simply gets moved into place; new programs
    using that DLL will get the infected variant.

    This is not a new concept. DOS viruses did this sort of
    thing all the time, in addition to hiding themselves in
    RAM and vectoring to allow survival after a warm boot.
    Of course DOS had little to no protection; Linux viruses
    would have to have write access to the MBR, usually on
    /dev/hda, and therefore write access to /dev/hda:

    brw-rw---- 1 root cdrom 3, 0 2008-01-21 10:56 /dev/hda

    There are ways to check for modifications to files, and
    to look for known rootkits, but polymorphic viruses are
    not unknown in the Windows world, and could mutate into
    the Linux world -- though far more slowly, as most
    distros lock down /bin, /sbin, /usr/bin, /lib, /usr/lib,
    and /etc as a matter of course.

    And of course one can always try to play
    Fool The Admin(tm). Some trojans come disguised as
    highly desirable updates.

    In short: difficult, but not impossible.

    >
    >>
    >>> If you don't overwrite the operating system, you can't install a virus.

    >>
    >> Meaning replace one DLL with another?

    >
    > Gee, you got that right but what happens is that a payload is dropped,
    > it's not overwriting any thing. It is so disguised or named that it
    > can't be detected, easily.


    Depends on a number of things. In Linux, one can hide
    in plain sight, though a checksum/md5sum will show
    a discrepancy very readily:

    readlink("/lib/libc.so.6") = "/libc-2.7.so"
    open("/var/tmp/evilhack.so", O_RDWR|O_CREAT) = 4
    open("/lib/libc-2.7.so", O_RDONLY) = 5
    write(4,"...",...)
    write(4,"...",...)
    write(4,"...",...)
    close(4)
    rename("/var/tmp/evilhack.so", "/lib/libc-2.7.so")

    There are two devices preventing this sort of thing.

    [1] /lib/libc-2.7.so is not writable. Therefore, the
    DLL cannot be simply opened read/write. The
    hack is still doable but not as easily. The above
    attempts to take this into account.
    [2] /lib is not writable. Therefore the rename fails.
    The hack is now impossible, absent something like
    a ptrace buffer overflow which allows local root
    access.

    A third factor is also present:

    [3] If the hack is for a i386 system, it's specific to
    an i386 processor. An m68k-based system would be
    immune or very obviously damaged (as the executable
    would probably crash because the instructions are
    different).

    In Windows, [1] holds true but the Registry hackaround
    might be available (I'd have to look but presumably it's
    an area where one can put arbitrary startup scripts);
    next system reboot and one's virus gets nicely installed.

    >
    >
    > There are several tools that can help anyone that knows how to use them,
    > and they can look for them self from time to time. But that also
    > involves that the person sitting behind the wheel has some type of
    > knowledge of the O/S.
    >
    >
    >
    > Security is a process and it's not a given, like practicing safe hex. It
    > doesn't matter what O/S it being used. One puts the computer at risk
    > with reckless behavior, then the machine can get compromised. And it
    > doesn't matter what O/S is being used.
    >
    > In addition, on any given O/S platform, if a machine gets compromised,
    > which this is particularly true for the home user sector, then 99.9% of
    > the time, the end-user had involvement in it in someway. It just doesn't
    > happen by it self.


    100%. The usual vectors nowadays are emails and browsers.
    Also, one might hold the distro liable if one leaves a port
    open -- but that distro was created by a engineer. In the
    case of Windows, the distro owner is of course Microsoft.

    Viruses aren't infectious in themselves; both the computer
    and the distro are accomplices. With Linux, at least,
    pickiness is a given; the virus has to work much harder
    to inveigle itself into the system's good graces -- though
    the notions of phishing, pharming, and Trojans still apply.
    Do a good enough fake, and people will flock through your
    door straight down into the precipice.

    (It doesn't help that Javascript and Flash are
    general-purpose programming environments. Fortunately,
    both are sandboxed. ActiveX has its own issues.)

    --
    #191, ewill3@earthlink.net
    Windows Vista. It'll Fix Everything(tm).

    --
    Posted via a free Usenet account from http://www.teranews.com


  14. Re: Linux security vs Windows with A/V software and firewall.

    In comp.os.linux.advocacy, Cross Posting HO

    wrote
    on Tue, 22 Jan 2008 09:06:55 -0500
    <13pbu4193s5pc5c@corp.supernews.com>:
    > Peter Köhlmann wrote:
    >> Cross Posting HO wrote:
    >>
    >>> Thufir wrote:
    >>>> On Tue, 22 Jan 2008 01:50:59 +0000, AZ Nomad wrote:
    >>>>
    >>>>> On Tue, 22 Jan 2008 01:21:35 GMT, Thufir wrote:
    >>>>>> On Mon, 21 Jan 2008 17:11:50 +0000, AZ Nomad wrote:
    >>>>>>> Not only that, but without going after system files, worms and virii
    >>>>>>> are nearly impossible.
    >>>>>> What do you mean by "without going after system files..."?
    >>>>> which word don't you understand?
    >>>> It's the grammar I don't follow. The worm and virii "go
    >>>> after" (currupt?) system files (DLL's?).
    >>> A DLL is not a system file. A DLL is a Dynamic Link Library. You cannot
    >>> corrupt a DLL.

    >>
    >> Sure you can. What would hinder a virus to overwrite part of the DLL and/or
    >> append itself to it?

    >
    > Comon man, the application that was using the DLL legitimately would
    > start to blow up, and it would be a sure sign of trouble. But that would
    > take for you to know something about OOp(s) programming.


    Assuming the DLL is writable in the first place.

    Interestingly, it appears that they are, so I have no idea how
    Linux would prevent such a thing absent turning off writability.
    It's an easy prototype[*]:

    --- main1.c ---
    #include
    extern void getsomeline();
    int main(int argc, char **argv)
    {
    getsomeline();
    return 0;
    }
    ---
    --- dll1.c ---
    #include
    void getsomeline()
    {
    char buffer[1024];
    printf("Type in a line\n");
    fgets(buffer, sizeof(buffer), stdin);
    printf("Got line %s\n", buffer);
    return;
    }
    ---
    --- build.sh ---
    #!/bin/sh
    gcc -c -fpic dll1.c -o dll1.o
    gcc -shared -o dll1.so dll1.o
    gcc -c main1.c -o main1.o
    gcc -o a.out main.o dll1.so
    ---

    and then one simply runs it, with the modifier to tell it
    where to look for the DLL, otherwise a.out won't be able
    to find it.

    LD_LIBRARY_PATH=. ./a.out

    While it's waiting patiently for your input, go to another
    terminal window and corrupt the DLL.

    echo 'hahahahahaha!' > dll1.so

    Now watch it crap over itself. For my one experiment it
    decided to do a bus error.

    The fix, of course, is more or less along the lines of

    chmod -w dll1.so

    (Note that DLLs must be readable and executable to function properly.)

    [rest snipped]
    [*] In a more realistic setting one would put the extern
    declaration in a .h file and create a Makefile.
    For such a small project it's not worth the trouble;
    the changes are trivial and left to the interested developer.

    --
    #191, ewill3@earthlink.net
    Useless C/C++ Programming Idea #10239993:
    char * f(char *p) {char *q = malloc(strlen(p)); strcpy(q,p); return q; }

    --
    Posted via a free Usenet account from http://www.teranews.com


  15. Re: Linux security vs Windows with A/V software and firewall.

    On Tue, 22 Jan 2008 08:50:47 -0800, The Ghost In The Machine wrote:
    >In comp.os.linux.advocacy, Cross Posting HO
    >
    > wrote
    >on Tue, 22 Jan 2008 09:06:55 -0500
    ><13pbu4193s5pc5c@corp.supernews.com>:
    >> Peter Köhlmann wrote:
    >>> Cross Posting HO wrote:
    >>>
    >>>> Thufir wrote:
    >>>>> On Tue, 22 Jan 2008 01:50:59 +0000, AZ Nomad wrote:
    >>>>>
    >>>>>> On Tue, 22 Jan 2008 01:21:35 GMT, Thufir wrote:
    >>>>>>> On Mon, 21 Jan 2008 17:11:50 +0000, AZ Nomad wrote:
    >>>>>>>> Not only that, but without going after system files, worms and virii
    >>>>>>>> are nearly impossible.
    >>>>>>> What do you mean by "without going after system files..."?
    >>>>>> which word don't you understand?
    >>>>> It's the grammar I don't follow. The worm and virii "go
    >>>>> after" (currupt?) system files (DLL's?).
    >>>> A DLL is not a system file. A DLL is a Dynamic Link Library. You cannot
    >>>> corrupt a DLL.
    >>>
    >>> Sure you can. What would hinder a virus to overwrite part of the DLL and/or
    >>> append itself to it?

    >>
    >> Comon man, the application that was using the DLL legitimately would
    >> start to blow up, and it would be a sure sign of trouble. But that would
    >> take for you to know something about OOp(s) programming.


    >Assuming the DLL is writable in the first place.


    >Interestingly, it appears that they are, so I have no idea how
    >Linux would prevent such a thing absent turning off writability.
    >It's an easy prototype[*]:


    In linux, the user doesn't own the system files and can't write to them.
    Case closed.


  16. Re: Linux security vs Windows with A/V software and firewall.

    In comp.os.linux.advocacy, AZ Nomad

    wrote
    on Tue, 22 Jan 2008 18:31:49 -0000
    :
    > On Tue, 22 Jan 2008 08:50:47 -0800, The Ghost In The Machine wrote:
    >>In comp.os.linux.advocacy, Cross Posting HO
    >>
    >> wrote
    >>on Tue, 22 Jan 2008 09:06:55 -0500
    >><13pbu4193s5pc5c@corp.supernews.com>:
    >>> Peter Köhlmann wrote:
    >>>> Cross Posting HO wrote:
    >>>>
    >>>>> Thufir wrote:
    >>>>>> On Tue, 22 Jan 2008 01:50:59 +0000, AZ Nomad wrote:
    >>>>>>
    >>>>>>> On Tue, 22 Jan 2008 01:21:35 GMT, Thufir wrote:
    >>>>>>>> On Mon, 21 Jan 2008 17:11:50 +0000, AZ Nomad wrote:
    >>>>>>>>> Not only that, but without going after system files, worms and virii
    >>>>>>>>> are nearly impossible.
    >>>>>>>> What do you mean by "without going after system files..."?
    >>>>>>> which word don't you understand?
    >>>>>> It's the grammar I don't follow. The worm and virii "go
    >>>>>> after" (currupt?) system files (DLL's?).
    >>>>> A DLL is not a system file. A DLL is a Dynamic Link Library. You cannot
    >>>>> corrupt a DLL.
    >>>>
    >>>> Sure you can. What would hinder a virus to overwrite part of the DLL and/or
    >>>> append itself to it?
    >>>
    >>> Comon man, the application that was using the DLL legitimately would
    >>> start to blow up, and it would be a sure sign of trouble. But that would
    >>> take for you to know something about OOp(s) programming.

    >
    >>Assuming the DLL is writable in the first place.

    >
    >>Interestingly, it appears that they are, so I have no idea how
    >>Linux would prevent such a thing absent turning off writability.
    >>It's an easy prototype[*]:

    >
    > In linux, the user doesn't own the system files and can't write to them.
    > Case closed.
    >


    Until a local root exploit is found and exploited.
    Fortunately, those are extremely rare.

    --
    #191, ewill3@earthlink.net
    Been there, done that, didn't get the T-shirt.

    --
    Posted via a free Usenet account from http://www.teranews.com


  17. Re: Linux security vs Windows with A/V software and firewall.

    Peter Köhlmann wrote:
    > Cross Posting HO wrote:
    >
    >> Peter Köhlmann wrote:
    >>
    >>> Hint, you typical clueless wintendo luser: It is practically the same
    >>> procedure as with EXE files
    >>>

    >>
    >> And you see, that's the problem with people that use Linux, and why
    >> Linux will never appeal to the mases it will never happen, which is your
    >> ****ed-up take on things and people like you.
    >>
    >> Because once they step in to a NG such as this to start asking
    >> questions, people like you will try to decapitate them.
    >>
    >> You're ****ed-up and this NG is ****ed-up.

    >
    > Translation: You got your ass handed, and can't cope with the situation.


    Translation: You got your head so far up your ass and so deep that you
    can't smell yourself, to know that you're ****ed-up and you stink.
    >
    > You have to be shown to be utterly incompetent, and that while you where
    > claiming to earn your living with the exact stuff you obviously know
    > nothing about.
    >
    > It must suck to be you


    What it is, is that you somehow got a hold of a computer and an O/S
    running a bunch of programs written by Human Beings, and it all went to
    your head, partner. It blew your head up bigger than a Zeppelin, and now
    you think you are Superman.

    You like to run your mouth. All you got to do is show some kind of
    documented proof to back your claims up, because you running your mouth
    is not good enough, partner. If you can't come-up with some document
    proof other than you running your damn mouth, then your Superman lip
    service is moot.

    That's all you have to do is back your ****-up, Superman -- back it up.



  18. Re: Linux security vs Windows with A/V software and firewall.

    The Ghost In The Machine wrote:
    > In comp.os.linux.advocacy, Cross Posting HO
    >
    > wrote
    > on Tue, 22 Jan 2008 08:14:33 -0500
    > <13pbr1qijblqv8a@corp.supernews.com>:
    >> Thufir wrote:
    >>> On Tue, 22 Jan 2008 01:50:59 +0000, AZ Nomad wrote:
    >>>
    >>>> On Tue, 22 Jan 2008 01:21:35 GMT, Thufir wrote:
    >>>>> On Mon, 21 Jan 2008 17:11:50 +0000, AZ Nomad wrote:
    >>>>>> Not only that, but without going after system files, worms and virii
    >>>>>> are nearly impossible.
    >>>>> What do you mean by "without going after system files..."?
    >>>> which word don't you understand?
    >>> It's the grammar I don't follow. The worm and virii "go
    >>> after" (currupt?) system files (DLL's?).

    >> A DLL is not a system file. A DLL is a Dynamic Link Library. You cannot
    >> corrupt a DLL. You can replace a DLL with another DLL that has dubious
    >> intent. But most of the time a worm or virus comes as its own standalone
    >> process or it will seek a host like Svchost.exe or Dllhost.exe or other
    >> such exe(s) that act as the host for a DLL.

    >
    > I'll admit to wondering about that. A DLL could easily
    > be modified, if one has write access (and no one's using
    > the inode; this is a quirk Linux to some extent shares
    > with Windows, though in Linux it's far less visible).
    > Of course with Linux only root has write access to most
    > of the system DLLs, though one can modify things so that
    > bin is the owner and no one has write access, or /usr is
    > mounted read-only, or /bin and /sbin are in the initialboot
    > RAM drive, etc., with sufficiently clever boot scripts.


    The important thing to remember is that the DLL has a contract between
    the client and itself. The contract will be the interfaces that the
    client will use to access the properties and methods of that DLL.

    If the contract is broken, a method within the DLL is not there anymore
    or the DLL starts returning unexpected results to the client, then the
    client is liable to go down, and most likely the client is going down.

    You see it all the time on the MS platform, the DLL hell that are
    associated with the DLL hell issues on the platform.

    I was in a situation on a XP development machine today doing some WEB
    development for a .Net Web service I am developing. I had a file pathing
    I was pulling from a Web.config that was pointing to a file share on the
    HD. I was testing and wanting to write some files to the file share. I
    got the file pathing messed up where the Web service was pointing to the
    System32 directory. .Net wouldn't let it happen, even with admin rights
    on the machine.


    >
    > (In a Windows system, things get a little sloppy on most
    > installations.)
    >
    > It does not appear all that difficult to add a section to
    > the DLL with some dangerous position-independent code,
    > and modify Elf32_Ehdr.e_entry (see /usr/include/elf.h).
    > Upon initial load the virus gains control. He would
    > probably want to add his section to other surrounding DLLs
    > (if they're not already affected), and then proceed to the
    > original e_entry, which he's carefully preserved someplace.
    >
    > The user might notice a little additional disk activity.
    >
    > Since DLLs are read-only if in use (ETXTBSY), the virus
    > writer would probably have to have write access to /bin
    > as well, to allow rename() to work. A temporary scratch
    > area is also indicated (/tmp or /var/tmp). Once the new
    > DLL is ready it simply gets moved into place; new programs
    > using that DLL will get the infected variant.
    >
    > This is not a new concept. DOS viruses did this sort of
    > thing all the time, in addition to hiding themselves in
    > RAM and vectoring to allow survival after a warm boot.
    > Of course DOS had little to no protection; Linux viruses
    > would have to have write access to the MBR, usually on
    > /dev/hda, and therefore write access to /dev/hda:
    >
    > brw-rw---- 1 root cdrom 3, 0 2008-01-21 10:56 /dev/hda
    >
    > There are ways to check for modifications to files, and
    > to look for known rootkits, but polymorphic viruses are
    > not unknown in the Windows world, and could mutate into
    > the Linux world -- though far more slowly, as most
    > distros lock down /bin, /sbin, /usr/bin, /lib, /usr/lib,
    > and /etc as a matter of course.
    >
    > And of course one can always try to play
    > Fool The Admin(tm). Some trojans come disguised as
    > highly desirable updates.
    >
    > In short: difficult, but not impossible.
    >
    >>>> If you don't overwrite the operating system, you can't install a virus.
    >>> Meaning replace one DLL with another?

    >> Gee, you got that right but what happens is that a payload is dropped,
    >> it's not overwriting any thing. It is so disguised or named that it
    >> can't be detected, easily.

    >
    > Depends on a number of things. In Linux, one can hide
    > in plain sight, though a checksum/md5sum will show
    > a discrepancy very readily:
    >
    > readlink("/lib/libc.so.6") = "/libc-2.7.so"
    > open("/var/tmp/evilhack.so", O_RDWR|O_CREAT) = 4
    > open("/lib/libc-2.7.so", O_RDONLY) = 5
    > write(4,"...",...)
    > write(4,"...",...)
    > write(4,"...",...)
    > close(4)
    > rename("/var/tmp/evilhack.so", "/lib/libc-2.7.so")
    >
    > There are two devices preventing this sort of thing.
    >
    > [1] /lib/libc-2.7.so is not writable. Therefore, the
    > DLL cannot be simply opened read/write. The
    > hack is still doable but not as easily. The above
    > attempts to take this into account.
    > [2] /lib is not writable. Therefore the rename fails.
    > The hack is now impossible, absent something like
    > a ptrace buffer overflow which allows local root
    > access.
    >
    > A third factor is also present:
    >
    > [3] If the hack is for a i386 system, it's specific to
    > an i386 processor. An m68k-based system would be
    > immune or very obviously damaged (as the executable
    > would probably crash because the instructions are
    > different).
    >
    > In Windows, [1] holds true but the Registry hackaround
    > might be available (I'd have to look but presumably it's
    > an area where one can put arbitrary startup scripts);
    > next system reboot and one's virus gets nicely installed.
    >
    >>
    >> There are several tools that can help anyone that knows how to use them,
    >> and they can look for them self from time to time. But that also
    >> involves that the person sitting behind the wheel has some type of
    >> knowledge of the O/S.
    >>
    >>
    >>
    >> Security is a process and it's not a given, like practicing safe hex. It
    >> doesn't matter what O/S it being used. One puts the computer at risk
    >> with reckless behavior, then the machine can get compromised. And it
    >> doesn't matter what O/S is being used.
    >>
    >> In addition, on any given O/S platform, if a machine gets compromised,
    >> which this is particularly true for the home user sector, then 99.9% of
    >> the time, the end-user had involvement in it in someway. It just doesn't
    >> happen by it self.

    >
    > 100%. The usual vectors nowadays are emails and browsers.
    > Also, one might hold the distro liable if one leaves a port
    > open -- but that distro was created by a engineer. In the
    > case of Windows, the distro owner is of course Microsoft.
    >
    > Viruses aren't infectious in themselves; both the computer
    > and the distro are accomplices. With Linux, at least,
    > pickiness is a given; the virus has to work much harder
    > to inveigle itself into the system's good graces -- though
    > the notions of phishing, pharming, and Trojans still apply.
    > Do a good enough fake, and people will flock through your
    > door straight down into the precipice.
    >
    > (It doesn't help that Javascript and Flash are
    > general-purpose programming environments. Fortunately,
    > both are sandboxed. ActiveX has its own issues.)


    COM and COM solutions are coming to an end on the MS platform, as .NET
    is slowly taking over, and .NET solutions have no need for the registry.

    A lot of things that are happening now on the Windows platform as far as
    vulnerabilities are concerned are coming to an end and will not be so
    easily archived in the future.

    You might think that .Net is only a Web centric or Web services
    solution, but .Net is much much more than that, and it will take over on
    the MS platform. It's not happening as fast as it should for the home
    consumer market.

    BTW, Win 2k3 server and II6 is as secure a solution as Linux and Apache,
    in the right hands. And the platform is moving fast in the Web server
    market with .Net.

    Java has nothing right now that can match .Net. Java needs to come-up
    with something and soon.

    http://news.netcraft.com/archives/20...er_survey.html

    You're the only one I have seen post in this NG that's not loaded with a
    bunch of lip services.

    I read your post with interest, and I enjoyed it.


  19. Re: Linux security vs Windows with A/V software and firewall.

    On Tue, 22 Jan 2008 18:43:15 -0500, Cross Posting HO wrote:

    > Peter Köhlmann wrote:
    >> Cross Posting HO wrote:
    >>
    >>> Peter Köhlmann wrote:
    >>>
    >>>> Hint, you typical clueless wintendo luser: It is practically the same
    >>>> procedure as with EXE files
    >>>>
    >>>
    >>> And you see, that's the problem with people that use Linux, and why
    >>> Linux will never appeal to the mases it will never happen, which is your
    >>> ****ed-up take on things and people like you.
    >>>
    >>> Because once they step in to a NG such as this to start asking
    >>> questions, people like you will try to decapitate them.
    >>>
    >>> You're ****ed-up and this NG is ****ed-up.

    >>
    >> Translation: You got your ass handed, and can't cope with the situation.

    >
    > Translation: You got your head so far up your ass and so deep that you
    > can't smell yourself, to know that you're ****ed-up and you stink.
    >>
    >> You have to be shown to be utterly incompetent, and that while you where
    >> claiming to earn your living with the exact stuff you obviously know
    >> nothing about.
    >>
    >> It must suck to be you

    >
    > What it is, is that you somehow got a hold of a computer and an O/S
    > running a bunch of programs written by Human Beings, and it all went to
    > your head, partner. It blew your head up bigger than a Zeppelin, and now
    > you think you are Superman.
    >
    > You like to run your mouth. All you got to do is show some kind of
    > documented proof to back your claims up, because you running your mouth
    > is not good enough, partner. If you can't come-up with some document
    > proof other than you running your damn mouth, then your Superman lip
    > service is moot.
    >
    > That's all you have to do is back your ****-up, Superman -- back it up.


    Kohlmann is an expert on every topic.
    A true legend in his own mind.

    Here is Peter Kohlmann explaining how video works:

    http://groups.google.com/group/comp....8d7bbe0fe46061

    Kohlmann is yet another basement dweller like his hero Hans Reiser.

  20. Re: Linux security vs Windows with A/V software and firewall.

    Peter Köhlmann wrote:

    > Translation: You got your ass handed, and can't cope with the
    > situation.
    >
    > You have to be shown to be utterly incompetent,



    Don't worry, CPH, when a dumbkopf like Kohlmann accuses you of incompetence,
    you know you're his owner.


    Here's where the scumbag accused me of rigging screenshots by turning
    off anti-aliasing:

    > http://groups.google.com/group/comp....e012c465a663cf
    >
    > "You mean, you deliberately selected different fonts/fontsizes?
    > And deselected Anti-aliasing too for KDE?
    > Figures, after all you are one of the most dishonest widiots around
    > here"



    And here's later that same day, where the scumbag contradicts himself and
    claims anti-aliasing has no effect on
    screen shots:

    > http://groups.google.com/group/comp....8d7bbe0fe46061
    >
    > " BTW, it is so simple to test for yourself.
    > Do a screen-shot of a text. Now disable anti-aliasing
    > Do again screen-shot of same text.
    > Compare both. They are exactly the same"



    He never did apologize for the rude, incorrect accusation.




+ Reply to Thread
Page 3 of 4 FirstFirst 1 2 3 4 LastLast