Tag Info

New answers tagged

0

This is very difficult to answer, as no one here does know how your application is built. As long as you are not executing (either directly or indirectly) any system commands your application should be save. There is only a risk when you execute commands (either directly or indirectly) in the shell out of your application. This risk is very high if you ...


2

I have run the official test script on my Samsung Galaxy Tab 10.1 and it indicates it is vulnerable. This device was just out of the box and has not been rooted.


1

To add to what Mark said, it's also worth noting that execlp, execvp, and execvpe all invoke /bin/sh, as that's how they perform their path lookups. So, even without the 2nd-generational effects Mark mentions, just using the exec* family of functions does not guarantee bash will not be invoked. The correct fix is to make sure you have installed a patched ...


5

Wrong on both counts. In order to exploit the "shellshock" vulnerability, an attacker needs to control at least one environment variable (easy to do through CGI, SSH, or DHCP), and bash needs to be invoked at some point with the modified environment: directly as the result of an exec(), indirectly through system() or equivalent, highly indirectly through ...


7

Not out-of-the-box. I know of no Android or iOS device running a bash shell. Some people might, on their rooted devices, but that will be only a few.


1

A stealth scan as it is commonly called is a half open TCP connection. Rather than: SYN -> <- SYN/ACK ACK -> it goes SYN -> <- SYN/ACK RST -> It's only referred to as stealth because many applications log a connection on its listening port. As this scan never completes the TCP connection, no log entry is made. Its in no way undetectable. The ...


1

First rule to remember is that you don't perform tasks as root unless they have to be performed as root. This part reduces the risk of doing damage by a typo or other mistake. It also reduces the risk of damage if the tools you are using happen to have a security vulnerability. Additionally accounts should only have the privileges they need and nothing ...


0

Thanks to everyone for answers, it's been really helpful. FWIW I'm posting my own answer for completeness, which is basically logging in as non-root user with SSH key, disallowing passwords. It's a VPS server which only I have access to which only runs a couple of sensitive services. To that end, I want it to be as secure as possible with as little ...


1

mricon brought up two excellent points for not using root login in a multi-user system. I just want to add a counter-point for using root login. If I need to rsync config files to the server, I can do it in one step using root login instead of uploading to the home directory of a user, then do su or sudo to rsync again into the /etc folder. Of course, I am ...


2

I always review the Digital Ocean when I provision a VPS follow these steps. Add a new user (standard command) Grant this new user root privileges by running visudo and adding your username under the one for root in the section titled "# User privilege specification". Effectively give yourself the same privileges as root Change the port SSH listens on by ...


5

This recommendation is most relevant on systems where multiple people can perform root-level operations. The Linux auditing daemon can distinguish "UID" and "effective UID", so user "bob" who does "sudo -i" and then performs a root-level operation will show up in audit logs as "user bob acting as user root". So, if you track changes to files in /etc, or ...


1

I think on a server the "don't login as root" recommendation isn't as hard. If you are on a desktop, you don't use root privileges most time. But if you are on a server, most time you use it is some maintenance task. While you can give people who only have to care for the webserver limited accounts, if you are the admin of the server, you can give yourself ...


2

What I normally do myself is configure log on to the root account, configure the server with sudo (adding myself to the sudoers) and then not permit root login anymore through SSH. I don't see a reason why you should not be able to work like this, but should you have a valid case yourself, using a key and a password is normally good protection (it's ...


1

Setting up system to be hacked and judging the results is commonly known as a Capture The Flag (CTF). There are a lot of open source CTFs out there, root-the-box is a great CTF that focuses more on post-exploitation and has puzzles for neophytes. There is also Damn Vulnerable Linux, which is an educational tool. A more simplistic CTF would be to have ...


3

I can think of a few ideas: put the codes inside a file running at boot, discoverable when the user run strings on it put the codes on suid scripts (you should never ever have suid scripts) put codes on world-writable binaries on /sbin put codes on world-readable config files somewhere put codes on tmp files put codes as a chain name on iptables Things ...


2

The execute bit permission is checked by the kernel on executing the exec(2) (and cousins) system call. You will need it only to execute programs at the kernel level. Only programs with that bit on (whichever hits to you as the owner, group or others is what is being checked) can be exec()ed by the kernel. Other different thing is what the shell does when ...


4

I'm surprised no one else has referred to another use of +x bit: directories. Maybe you are after execution of (example) something in /bin (shell script or otherwise), but there is more to execute bits than files (of course, a directory IS a file but it is a different kind of file). If you have +x access on a directory but -r on that same directory, then ...


4

There is a readymade way to execute an arbitrary file: pass it as an argument to the dynamic linker (which is the appropriate interpreter for a dynamically loaded executable). E.g. under Linux, cp /bin/ls /tmp/ chmod -x /tmp/ls /lib/ld-linux.so.2 /tmp/ls However, this comes with the same restriction as reading the file and jumping to code: the setuid bits ...


4

If you for some reason want to keep the binary code secret, you can make the program executable without being readable. This is not useful if those users have physical access to the machine. It is also not useful if the source or binary code is widely available. So this is a fairly limited use case. If the program has a setuid or setgid bit, execute access ...


21

You can set the execute bit, but not the read bit, on an executable file. That way, noone will be able to copy the file, but people can execute it anyway. This is quite pointless today, because a) it works for compiled programs only, not with scripts (on most systems); b) these days, with 90% of all unixes being linux, people can copy executables from just ...


64

There's an even easier way to bypass the "execute" permission: copy the program into a directory you own and set the "execute" bit. The "execute" permission isn't a security measure. Security is provided at a lower level, with the operating system restricting specific actions. This is done because, on many Unix-like systems (especially in the days of ...



Top 50 recent answers are included