간만에 쓰는군요...에헴~
보안 관련 업무하시는 분들은 대부분 secunia의 뉴스레터를 받아보실텐데, 오늘은 아주 재미난 걸 읽었습니다.
---------------------------------------------------------------------------------------------------
- Danske Bank e-Sec Control Module Error Logging Buffer Overflow -
======================================================================
Table of Contents
Affected Software....................................................1
Severity.............................................................2
Description of Vulnerability.........................................3
Solution.............................................................4
Time Table...........................................................5
Credits..............................................................6
References...........................................................7
About Secunia........................................................8
Verification.........................................................9
======================================================================
1) Affected Software
* Danske Bank Danske e-Sec Control Module ActiveX control
(DanskeSikker.ocx) version 3.1.0.48.
NOTE: Other versions may also be affected.
======================================================================
2) Severity
Rating: Highly critical
Impact: System compromise
Where: Remote
======================================================================
3) Description of Vulnerability
Secunia Research has discovered a vulnerability in Danske Bank Danske
e-Sec Control Module ActiveX control, which can be exploited by
malicious people to compromise a user's system.
The vulnerability is caused by a boundary error in DanskeSikker.ocx
within an error logging function. This can be exploited to cause a
stack-based buffer overflow by passing overly long input to certain
methods when the ActiveX control has been initialised in a specific
manner.
Successful exploitation allows execution of arbitrary code when e.g.
visiting a malicious web site.
======================================================================
4) Solution
Set the kill-bit for the ActiveX control.
The vendor is reportedly working on a fix.
======================================================================
5) Time Table
16/04/2008 - Vendor notified.
16/04/2008 - Vendor response.
25/06/2008 - Status update requested.
27/06/2008 - Vendor response (responsible person is on holiday, but
will provide status update ASAP).
24/07/2008 - Status update requested.
13/08/2008 - Status update requested.
13/08/2008 - Vendor response.
25/08/2008 - Status update requested.
18/09/2008 - Vendor informed that advisory is going out today.
18/09/2008 - Vendor calls asking for extension.
05/11/2008 - Status update requested.
05/11/2008 - Vendor response (currently no progress).
10/11/2008 - Vendor informed about Secunia Reserach disclosure policy
and informed that a new status update will be requested
in a couple of months.
02/03/2009 - Status update requested.
11/03/2009 - Status update requested again.
17/03/2009 - Vendor provides status update (working on a fix).
20/03/2009 - Vendor reminded of Secunia Research disclosure policy.
Advisory will not be coordinated for more than 1 year.
16/04/2009 - Public disclosure.
======================================================================
6) Credits
Discovered by Carsten Eiram, Secunia Research.
상기의 내용을 보신 분이 많으실텐데, 본인이 관심있게 본 부분은 바로 Time Table.
Bold로 표시를 해놓았으니 확인하셨겠지만, 근 1년간 Vendor에 Patch를 요구하여 Fix를 시킨 후에 발표를 하였군여.
Danske Bank는 말 그대로 은행인 '덴마크 금융그룹'입니다. 코펜하겐에 본사를 둔...
취약점에 대한 응대는 즉시 이루어졌으나, 내부처리가 국내 수준만큼 느렸나보군요.
국내도 최근에는 취약점에 대한 대응 속도가 이전보다 훨씬 빨라지고 있습니다만,
아직은 그래도 미흡하다는 느낌을 받습니다. (본인 경험상)
제대로된 보안담당자, 보안관리자가 있는 곳은 빠른 편이고, 거기에 보안담당부서가 파워가 있다면 훨씬 빠르죠.
하지만, 보통은 아직은 좀 느린 편입니다.
상기의 경우는 Secunia에서는 지속적으로 연락해서 취약점을 FIX 시키는 집요함을 보였네요...게다가 발표까지....ㅋㅋ
국내에선 어림도 없었을텐데...@@
Secunia의 집요함과 보안에 대한 열정에 박수를 보냅니다.
국내에서 저렇게 한다면?? 음...결과가 힘들어서 상상도 하기 싫군요..ㅋ
PS : 제 사견입니다만, 정말 정말 vendor 사에서 원하지 않는다면 FIX 확인 후 발표를 하지 않는 것이 오히려 더 좋을 듯 합니다.
