링크가 복사되었습니다!

80% 문제: RunSafe, 숨겨진 AI 위험 노출

RunSafe Security의 새로운 보고서에 따르면 현재 83.5%의 중요 시스템이 AI 생성 코드를 실행하지만 메모리 안전 보호는 속도를 따라가지 못하고 있습니다. 이 보고서는 취약점의 물리학과 향후 경로를 자세히 다룹니다.

🌐
기계 번역

이 기사는 영어 원문에서 자동 번역되었습니다. 영어 원문 읽기

파란색 로컬 보안 영역에 대해 흔적을 통해 확산되는 빨간색 디지털 손상을 보여주는 회로 기판의 매크로 보기입니다.

조용한 임베디드 시스템 혁명이 이제 목소리를 높였다. RunSafe Security의 2025년 새로운 보고서에 따르면, 80.5% 의 임베디드 엔지니어들이 이제 AI 도구를 사용하여 코드를 작성하고 있으며, 놀랍게도 83.5% 는 그 AI 생성 코드를 프로덕션 환경에 직접 배포했다.

다른 산업이라면 생산성의 승리라고 축하했을 것이다. 하지만 임베디드 시스템의 세계에서 (인슐린 펌프, 산업용 액추에이터, 자동차 제동 시스템을 제어하는 코드), 이것은 속도와 타당성의 끔찍한 분리를 의미한다.

이 보고서는 “AI in Embedded Systems: AI Is Here. Security Isn’t” 라는 제목으로, 산업이 위험한 전환점에 있는 그림을 그리고 있다. 엔지니어들은 이전보다 더 빠르게 코드를 작성하고 있으며, 안전하기 위해 설계되지 않은 언어를 사용하고 있으며, 쉽게 패치할 수 없는 하드웨어에 배포하고 있다.

기술 심층 분석: 왜 ‘좋은’ 코드가 깨질까

코드 품질이 주요 관심사가 아니다. LLM은 유효한 구문을 생성한다.

문제는 C와 C++이 완벽한 개발자 경계를 요구하는 본질적으로 안전하지 않은 언어라는 것이다. 그런데 AI 모델은 확률적 토큰 예측기이므로 이를 구조적으로 보장할 수 없다.

메모리 안전 갭

현대적인 고급 애플리케이션(Python, Rust, Go로 작성된)에서는 언어 런타임이 메모리 할당을 처리한다. 객체를 생성하면 시스템이 공간을 찾는다. 사용을 멈추면 가비지 컬렉터가 해제한다.

임베디드 C/C++에서는 당신이 가비지 컬렉터다. 메모리를 수동으로 할당(malloc)하고 수동으로 해제(free)해야 한다. 실수를 하면 오류를 받는 것이 아니라 취약점을 만드는 것이다.

Advertisement

RunSafe 보고서는 이 “수동 변속기” 방식이 AI의 속도와 충돌하고 있음을 강조한다. AI가 JSON 스트림용 50줄의 파서를 생성할 때, 종종 표준적이고 효율적인 C 패턴을 사용한다. 그러나 메모리 레이아웃의 맥락을 고려하는 일은 거의 없다.

  • 버퍼 오버플로우: AI는 데이터가 버퍼에 맞는지 엄격하게 확인하지 않고 데이터를 버퍼에 쓴다. 데스크톱 앱에서는 프로그램이 충돌한다. MMU(메모리 관리 장치) 없는 임베디드 컨트롤러에서는 명령 포인터를 덮어쓰고 공격자에게 장치의 제어권을 준다.
  • 해제 후 사용 (UAF): AI가 포인터를 올바르게 해제하지만 코드의 다른 곳에 매달린 참조를 남긴다. 나중에 로직이 해제된 메모리에 접근하려고 한다. 공격자가 힙을 악의적인 데이터로 스프레이했다면, 이제 공격자가 실행을 소유한다.

공격 표면 승수

보고서의 통계가 무서운 이유는 표면적이다. 53% 의 응답자는 보안을 주요 관심사로 언급했지만, 91% 는 임베디드 보안에 대한 투자를 늘리고 있다. 그들은 파도가 오고 있다는 것을 알고 있다.

전통적 개발은 코드량에 자연스러운 제한을 가한다. 인간 엔지니어는 하루에 C++ 줄을 많이 쓸 수 있으며, 좋은 팀은 그 코드를 검토한다. AI는 제한을 제거한다. 업계는 이제 기존 코드베이스에 광대한 양의 새로운 미검증 로직을 쏟아붓고 있다.

인간 코드 1만 줄당 중대한 메모리 결함이 1개 있고, AI가 엔지니어들로 하여금 1만 줄을 쓰던 시간에 10만 줄을 쓰게 한다면, 업계는 생산성만 증가시킨 것이 아니라 잠재적 취약점의 밀도를 한 자리 수 증가시킨 것이다.

맥락적 역사: 태만의 패턴

업계는 이 영화를 이전에 봤다, 다른 스크린에서일 뿐이다.

2000년대 초반 IoT 붐의 “모든 것 연결하기” 단계에서 Mirai 봇넷이 나왔다. 제조업체는 기본 비밀번호나 열린 텔넷 포트를 생각하지 않고 카메라와 DVR에 IP 스택을 붙이기 위해 서두르고 있었다. 그 결과는 타협된 토스터와 웹캠에서 구축된 대규모 DDoS 인프라였다.

2010년대에는 자동차 산업이 자동차에 인포테인먼트와 연결성을 추가하기 위해 서두르고 있었다. 그 결과는 Jeep Cherokee 해킹이었는데, 연구자들이 엔터테인먼트 시스템이 CAN 버스와 통신할 수 있었기 때문에 고속도로에서 차량의 변속기를 원격으로 죽일 수 있었다.

이제 2025년에, 코드 생성으로 다시 일어나고 있다. RunSafe 보고서는 73% 의 엔지니어가 AI 코드의 위험을 “중간 이상”으로 평가하지만, 배포 숫자(83.5%)는 그들이 어쨌든 진행하고 있음을 보여준다.

“스마트” 기능(예측 유지보수, 엣지 AI 처리, 음성 인터페이스)을 배송하라는 경제적 압력이 보안을 위해 필요한 엔지니어링 규율을 무시하고 있다.

Advertisement

대응 조치: 로드타임 함수 무작위화 (LFR)

코드에 대한 신뢰가 불가능하다면 (코드가 너무 많기 때문에) 그리고 30년의 C++을 하룻밤에 Rust로 다시 쓰는 것이 불가능하다면, 방어는 무엇인가?

보고서는 런타임 복원력을 가리킨다. 버그가 존재한다고 가정하면 버그를 이용할 수 없게 만들어야 한다.

임베디드 공간에서 이를 위한 가장 효과적인 기술 중 하나는 로드타임 함수 무작위화 (LFR) 이다.

작동 원리

표준 펌웨어 컴파일에서는 모든 함수가 정적이고 알려진 주소에 있다. calculate_voltage()는 항상 0x08001234에 있을 수 있다.

공격자는 이것을 좋아한다. 익스플로잇을 구축하려면 (Return-Oriented Programming 또는 ROP와 같이), 그들은 실행할 코드로 점프할 정확한 위치를 알아야 한다. 그들은 기존 코드의 작은 조각(가젯)을 함께 연결하여 악의적인 프로그램을 구축한다.

LFR은 이 체인을 끊는다.

  1. 컴파일 시간: 컴파일러는 절대 주소로 점프하지 않는 코드를 내보낸다. 대신 “스텁” 또는 조회 테이블로 점프한다.
  2. 로드 시간: 장치가 부팅될 때, 보안 로더가 카드를 섞는다. 모든 함수에 무작위로 실제 메모리 주소를 할당한다.
  3. 패칭: 로더는 조회 테이블을 업데이트하거나 메모리의 바이너리를 패치하여 호출이 계속 작동하도록 한다.

결과? 장치가 재부팅될 때마다(또는 구현에 따라 펌웨어가 업데이트될 때마다), 메모리 맵이 변경된다. Device A에서 작동하는 익스플로잇은 Device B를 충돌시킨다. 어제 작동한 익스플로잇은 재부팅 후에는 작동하지 않는다.

RunSafe의 이 기술의 독점적 구현이 견인력을 얻고 있는 이유는 소스 코드를 다시 쓸 필요가 없기 때문이다. 바이너리 수준에서 적용한다. 이것은 이미 런타임 보호를 사용하려고 하는 60% 의 응답자에게 중요하다.

앞으로의 분석: 5년 전망

2025년 보고서는 과도 기간의 스냅숏이다. 이 부문은 현재 AI 코드 생성의 “와일드 웨스트” 단계에 있다.

향후 5년간 세 가지 주요 변화가 예상된다:

  1. 실리콘 기반 보안의 부상: LFR과 같은 소프트웨어 완화가 실질적으로 의무가 될 것이다. 규제(EU의 사이버 복원력법과 유사함)는 아마도 중요 인프라 장치가 바이너리 무작위화 기능을 갖춰야 할 것이라고 요구할 것이다.
  2. Rust 전환: AI가 C++을 쉽게 작성하는 동안, Rust도 쉽게 작성한다. 메모리 안전 언어로 전환하는 마찰은 AI가 보일러플레이트를 처리할 때 감소할 것이다. 그러나 이것은 새로운 코드만 보호한다. 수십억 줄의 레거시 C/C++은 남아 있다.
  3. 책임 이동: AI 생성 코드가 물리적 장애를 일으킬 때 (예: 로봇 팔이 너무 빠르게 회전하거나, 배터리 관리 시스템이 실패할 때), 법적 대화는 “소프트웨어 버그”에서 “제품 책임”으로 이동할 것이다. 제조업체가 인간 검토나 런타임 보호 없이 안전-중요 코드를 생성하기 위해 AI를 사용했다면, 그것은 태만이다.

결론

RunSafe Security 2025년 보고서는 단순한 조사 모음이 아니다; 이것은 경고 신호다. 업계는 AI 생산성의 병을 열었으며, 다시 병에 넣을 방법은 없다.

생성되는 코드의 막대한 양은 수동 검토가 규모에서 수학적으로 불가능함을 의미한다. 모든 버그를 잡을 수 있다고 가장하는 것이 더 이상 가능하지 않다. 유일한 전진 경로는 코드가 깨진 것이라고 가정하고 그 코드가 기계에 해를 끼치지 않도록 거부하는 시스템을 구축하는 것이다.

2025년 임베디드 엔지니어의 업무는 더 이상 단순히 C 작성이 아니다. C가 누구도 해치지 않도록 유지하는 격리 필드를 설계하는 것이다.

수학적 부록: 익스플로잇의 확률

LFR의 가치를 모델링하려면 성공적인 ROP 체인 익스플로잇의 확률 P를 계산해야 한다. 표준 체인에는 k개의 가젯이 필요하다. 정적 메모리 맵에서 가젯 i를 알려진 위치에서 찾을 확률은 1이다.

정적 익스플로잇의 확률은 사실상 100%이다.

LFR을 사용하면, 함수에 대한 N개의 가능한 위치(슬롯)가 있고 공격자가 각 독립 가젯(단순화된 모델)에 대해 올바른 오프셋을 맞힐 확률이 1인 N 중 1이라면, 확률은 대략 1을 N의 k 제곱으로 나눈 것으로 떨어진다.

확률은 사실상 0이다.

겸손한 엔트로피(N=256)와 짧은 체인(k=3)으로도, 난이도는 확실성에서 1600만 분의 1로 급증한다.

출처 (6)

Advertisement

🦋 Bluesky 토론

Bluesky에서 토론하기

게시물 검색 중...