Announcement

Collapse
No announcement yet.

Malicious commands you shouldn't run.

Collapse
This is a sticky topic.
X
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Spaceboy
    replied
    It's the new <alt+f4>

    Leave a comment:


  • cold fusion
    replied
    Originally posted by Spaceboy View Post
    Anyone on a Linux server that doesn't know the init command is asking for trouble.
    I thought that when I was chatting to a mate on IRC, they asked how to check do something-or-other (I forget what exactly - but it wasn't that technical), I joked saying "init 0" and then a few moments later their ZNC timed out

    Leave a comment:


  • Spaceboy
    replied
    Anyone on a Linux server that doesn't know the init command is asking for trouble.

    Sun Solaris was my favourite with "init 5"... shutdown and power off - works better on those systems with Lights Out Management

    Leave a comment:


  • cold fusion
    replied
    Originally posted by andyn View Post
    Yup, 0 for system halt, 1 for single user mode, 6 for reboot, I think those are pretty much universal across all unixen. The others vary quite a lot though.
    Ah yes. I was getting 0 and 1 mixed up in my post. (though the end result is effectively the same in the context of a data centre dedi)

    Leave a comment:


  • andyn
    replied
    Do a restart as well?
    Yup, 0 for system halt, 1 for single user mode, 6 for reboot, I think those are pretty much universal across all unixen. The others vary quite a lot though.

    Leave a comment:


  • Salad Soup
    replied
    Originally posted by Plan9 View Post
    Old sticky bump, but I'm bored so thought I'd add a couple:

    Since you have a section on forkbombs, it seems fitting to include one of the most infamous Bourne shell ones:
    Code:
    :(){ :|:& };:
    Also, there's this one which many of the younger Linux users wouldn't be familiar with:
    Code:
    init 0
    All it does is shut the Linux / UNIX box down to maintenance mode. Which isn't a problem on desktops as you can just reboot the thing. However it's more of an issue of you're remotely administrating a Linux dedicated box as you'll lose all network connectivity to it and will need to wait for the datacenter operator to walk over to your rack to power cycle it.
    Doesn't
    Code:
    init 6
    Do a restart as well?

    Leave a comment:


  • cold fusion
    replied
    Old sticky bump, but I'm bored so thought I'd add a couple:

    Since you have a section on forkbombs, it seems fitting to include one of the most infamous Bourne shell ones:
    Code:
    :(){ :|:& };:
    Also, there's this one which many of the younger Linux users wouldn't be familiar with:
    Code:
    init 0
    All it does is shut the Linux / UNIX box down to maintenance mode. Which isn't a problem on desktops as you can just reboot the thing. However it's more of an issue of you're remotely administrating a Linux dedicated box as you'll lose all network connectivity to it and will need to wait for the datacenter operator to walk over to your rack to power cycle it.

    Leave a comment:


  • andyn
    replied
    Originally posted by Plan9 View Post
    That wouldn't fix the chmod -R 777 / issue I was referring to though as even a blank password would still need to be recorded in /etc/passwd. The problem isn't the password itself, it the permissions on the key config files.

    You could use the live CD to chmod the /etc/passwd back to the correct permissions, but if your system supports single user mode log ins then it would be easier to sign in that way. Particularly in server rooms where boxes don't always have CD ROMs hooked up nor KVMs, or the datacentre it remotely located so physical access isn't practical. In those situations you need a fix that would work via the out-of-band management.
    Oh, yeah, I see what you mean. TBH if you've globally reset the permissions on your entire file system your best bet is to revert from a backup, as even if you hacked it back to a usable state there could be security issues further down the line. It's a pretty catastrophic mistake .

    Leave a comment:


  • cold fusion
    replied
    Originally posted by andyn View Post
    If you've got physical access then normally you can just boot from a liveCD and reset your password to an empty string by editing /etc/password (and /etc/shadow if needed). Done that plenty of times in the past (though not very recently I'll admit - there may be some reason why this wouldn't work nowadays?). Obviously encrypted file systems etc would cause problems .
    That wouldn't fix the chmod -R 777 / issue I was referring to though as even a blank password would still need to be recorded in /etc/passwd. The problem isn't the password itself, it the permissions on the key config files.

    You could use the live CD to chmod the /etc/passwd back to the correct permissions, but if your system supports single user mode log ins then it would be easier to sign in that way. Particularly in server rooms where boxes don't always have CD ROMs hooked up nor KVMs, or the datacentre it remotely located so physical access isn't practical. In those situations you need a fix that would work via the out-of-band management.

    Leave a comment:


  • andyn
    replied
    Originally posted by Plan9 View Post
    Yeah, the /etc/passwd is one such file that's expected to have specific permissions (700 IIRC) otherwise log in managers refuse to work. And if you can't log in, then you've basically bricked your install (I say that, but I think you can still force your way in on many *nixes if you drop into single user mode)
    If you've got physical access then normally you can just boot from a liveCD and reset your password to an empty string by editing /etc/password (and /etc/shadow if needed). Done that plenty of times in the past (though not very recently I'll admit - there may be some reason why this wouldn't work nowadays?). Obviously encrypted file systems etc would cause problems .

    Leave a comment:


  • cold fusion
    replied
    Originally posted by Lorem-Ipsum View Post
    Its not that its just insecure. It breaks things. Certain things such as sudo etc... NEED certain permissions or they fail to work. It may even make some boxes fail to boot.
    Yeah, the /etc/passwd is one such file that's expected to have specific permissions (700 IIRC) otherwise log in managers refuse to work. And if you can't log in, then you've basically bricked your install (I say that, but I think you can still force your way in on many *nixes if you drop into single user mode)

    Leave a comment:


  • Lorem-Ipsum
    replied
    Originally posted by Mr. Grapes View Post
    ah ok, so just insecure then, not revoking all permissions form everything everywhere.

    so in that case, you'd also not want to ever run
    Code:
    chmod -R 000 /
    Its not that its just insecure. It breaks things. Certain things such as sudo etc... NEED certain permissions or they fail to work. It may even make some boxes fail to boot.

    Leave a comment:


  • Mr. Grapes
    replied
    ah ok, so just insecure then, not revoking all permissions form everything everywhere.

    so in that case, you'd also not want to ever run
    Code:
    chmod -R 000 /

    Leave a comment:


  • andyn
    replied
    Originally posted by Mr. Grapes View Post
    -R being revoke?

    ouch yes. much badness there...
    Recursive .

    Leave a comment:


  • Mr. Grapes
    replied
    -R being revoke?

    ouch yes. much badness there...

    Leave a comment:

Working...
X