ITC Advent Calendar(1) 2日目
https://adventar.org/calendars/2563
ブログに書くほどでもないのでGistに書こうと思う
ITC Advent Calendar(1) 2日目
https://adventar.org/calendars/2563
ブログに書くほどでもないのでGistに書こうと思う
OIC ITCreate Club Advent Calendar 2015 1日目ってことにしておいてください。
HTTPクライアント周りあまり触ったことなかったから触ってみたけどつらい。 これだけ書くのにハマったりしながら3時間位かかった…
試しにPixivのブックマークの1ページ目のイラストを保存するものを書いてみた
import java.security.AlgorithmParameters; | |
import java.security.Key; | |
import java.security.SecureRandom; | |
import javax.crypto.*; | |
import javax.crypto.spec.*; | |
import java.security.spec.*; | |
import org.apache.commons.codec.binary.Base64; |
Let's say somebody temporarily got root access to your system, whether because you "temporarily" gave them sudo rights, they guessed your password, or any other way. Even if you can disable their original method of accessing root, there's an infinite number of dirty tricks they can use to easily get it back in the future.
While the obvious tricks are easy to spot, like adding an entry to /root/.ssh/authorized_keys, or creating a new user, potentially via running malware, or via a cron job. I recently came across a rather subtle one that doesn't require changing any code, but instead exploits a standard feature of Linux user permissions system called setuid to subtly allow them to execute a root shell from any user account from the system (including www-data
, which you might not even know if compromised).
If the "setuid bit" (or flag, or permission mode) is set for executable, the operating system will run not as the cur
# | |
# STL GDB evaluators/views/utilities - 1.03 | |
# | |
# The new GDB commands: | |
# are entirely non instrumental | |
# do not depend on any "inline"(s) - e.g. size(), [], etc | |
# are extremely tolerant to debugger settings | |
# | |
# This file should be "included" in .gdbinit as following: | |
# source stl-views.gdb or just paste it into your .gdbinit file |