실행 파일과 공유 객체

하는 동안 뭔가를 알아 차렸다 find /bin -exec file {} \; .

file에서 명령은 일부 항목보고 /bin있다 shared objects, 다른 사람과 같은 동안executables . 예를 들어

/ bin / ntfsck :
ELF 64 비트 LSB 공유 객체 , x86-64, 버전 1 (SYSV),
GNU / Linux 2.6.24, ELID 동적으로 링크 (공유 라이브러리 사용), BuildID [sha1] = 312d93fd0d8653e7236a61db2e67b93c63225a00, 제거됨

에 대한 동일한 보고서 gawk

/ usr / bin / gawk : GNU / Linux 2.6.24, ELID
64 비트 LSB 공유 객체 , x86-64, 버전 1 (SYSV),
동적으로 링크 (공유 라이브러리 사용),
BuildID [sha1] = 76bb13aac7e212164bd6e0d7b8a5d92db44543c9, 제거됨

반면에 file대한이 /bin/echo있다 :

/ bin / echo : GNU / Linux 2.6.24, BuildID [sha1] = 193e75fc13e9c4599e772b8d79125a5934cf601c에서
ELF 64 비트 LSB 실행 파일 , x86-64, 버전 1 (SYSV),
동적으로 링크 됨 (공유 라이브러리 사용)

본질적으로 executable파일과 shared object파일 의 차이점이 무엇인지 알고 싶습니다 .

Tl; dr

컴파일 된 실행 파일은 공유 객체에 연결될 수 있지만 실행 파일에는 연결되지 않을 수 있다는 점 외에는 차이가 없습니다.

일반적으로 컴파일하는 방법은 두 가지가 있습니다 ^일을 실행은 :

• 정적 연결 사용 : 소스 코드에 포함 된 외부 라이브러리가 컴파일되고 컴파일 된 라이브러리 (또는 링커의 관점에서 객체)가 실행 파일 자체에 추가됩니다.
• 동적 링크 사용 : 소스 코드에 포함 된 외부 라이브러리는 컴파일되지만 컴파일 된 라이브러리 (또는 링커의 관점에서 오브젝트)에 대한 링크 는 실행 파일에 추가되며 컴파일 된 라이브러리 / 오브젝트는 런타임시 링커에 의해로드됩니다. 필요);

이러한 각 방법을 사용하면 장단점이 있지만 문제의 핵심은 아닙니다.

• /bin/ntfsck 과 /usr/bin/gawk 객체 공유 : 실행이 자신의 기능을 사용하도록 컴파일 한 다음에 링크 할 수있는이 수단을;
• /bin/echo실행 파일입니다. 즉, 실행 파일이 컴파일 되지 않은 다음 해당 기능을 사용하도록 링크 될 수 있습니다.

그래서 /bin/ntfsck및/usr/bin/gawk 하나가 forsaw있을 수 있으므로 기술적으로 컴파일 된 라이브러리 (또는 링커의 관점에서 개체),하지만, 아무것도 방지 실행으로 실행되는 공유 객체입니다.

참고로, file보고서 (각 보고서)는 다음과 같습니다.

동적으로 링크 됨 (공유 라이브러리 사용)

이는 각 공유 객체가 다른 공유 객체에도 동적으로 연결되어있을 가능성이 높다는 것을 의미합니다.

_{1. "프로파일"은 전처리, 컴파일 및 링크를 포함하여 더 광범위한 수용을 목적으로합니다.}

또 다른 차이점은 실행 파일 에 정의 된 진입 점 주소 오프셋 (즉, i386의 경우 0x08048000, x86의 경우 0x00400000, arm의 경우 0x00010000)이 있다는 것입니다.

공유 객체 파일은 라이브러리 일 수 있지만 실행 파일 일 수도 있습니다. 실행 파일 일 때는 그러한 오프셋이 없습니다. 공유 객체가 실행 되므로 대답 주소 공간 배치 무작위 (ASLR)를 사용하여 위치 독립 실행 (PIE)이다. 따라서 / proc / pid / maps 파일을 볼 때로드 된 세그먼트의 위치는 표준 실행 파일과 달리 실행마다 다릅니다.

이 기능의 기본 개념은 공격자가 반환 지향 프로그래밍 공격을 수행하지 못하도록하여 실행 파일에 보안을 추가하는 것입니다. 많은 관리자들은 Fedora 23 이후 또는 Ubuntu 17.10 이후로 PIE를 기본값으로 활성화 한 패키지를 만들기로 결정했습니다.