Có phải tất cả các mối đe dọa bảo mật được kích hoạt bởi lỗi phần mềm?


13

Hầu hết các mối đe dọa bảo mật mà tôi đã nghe nói đã phát sinh do lỗi trong phần mềm (ví dụ: tất cả các đầu vào không được kiểm tra chính xác, tràn ngăn xếp, v.v.). Vì vậy, nếu chúng tôi loại trừ tất cả các hack xã hội, tất cả các mối đe dọa bảo mật do lỗi? Nói cách khác, nếu không có lỗi, liệu sẽ không có mối đe dọa bảo mật nào (một lần nữa, ngoại trừ lỗi của con người như tiết lộ mật khẩu và những thứ khác)? Hoặc hệ thống có thể được khai thác theo cách không gây ra bởi lỗi?


4
Bạn có gọi khả năng tôi có thể đoán mật khẩu yếu là lỗi phần mềm không? Nếu bất cứ điều gì, đó là một vấn đề thiết kế, nhưng nó có thể thậm chí còn cơ bản hơn thế này.
Joachim Sauer

4
Bạn sẽ định nghĩa thiết kế kém là một lỗi?
StuperUser

1
Để hỗ trợ @StuperUser, trong liên kết " security.stackexchange.com/questions/25585/ mẹo " không có lỗi trong tập lệnh của Dave. Nhưng đó là thiết kế ngu ngốc.
Manoj R

1
Nếu chúng tôi loại trừ tất cả các lý do cho các vấn đề bảo mật, ngoại trừ lỗi, thì có.
andho

Có liên quan: trang
Trevor Powell

Câu trả lời:


25

Một lỗi được định nghĩa là phần mềm không hoạt động đến thông số kỹ thuật. Bây giờ nếu thông số kỹ thuật bị lỗi, đó không phải là lỗi phần mềm. Nếu một khách hàng câm yêu cầu tất cả mật khẩu phải là mã ba chữ số không có thời gian gia hạn giữa các mục bị lỗi, thì đó không phải là phần mềm đáng bị chê trách.

Nhiều hệ thống có "chế độ dịch vụ" có thể ghi đè bảo mật và trong khi quyền truy cập vào nó phải an toàn, các mã thường bị rò rỉ ra công chúng.

Những tiến bộ trong toán học thỏa hiệp các phương pháp mã hóa cũ. Một cái gì đó là an ninh khả thi 30 năm trước trở nên yếu hiện nay.

Có nhiều phương pháp đánh cắp dữ liệu thường bị bỏ qua. Một bàn phím không dây có phạm vi khoảng 2m, do ăng ten nhỏ và mã được gửi không được mã hóa. Đọc nó từ bên kia đường với ăng ten tốt là một phương pháp nổi tiếng.

Đôi khi sự đánh đổi bảo mật được thực hiện với nhận thức đầy đủ về hậu quả - hệ thống tiền điện tử mất thời gian và sức mạnh của CPU. Các ứng dụng giám sát nhúng thường gửi dữ liệu của họ theo cách dễ đọc cho công chúng bởi vì trước tiên, giá trị của việc thỏa hiệp dữ liệu là không đáng kể, và sau đó chi phí bổ sung để thực hiện bảo mật là không cần thiết.

Tất cả an ninh được dựa trên niềm tin. Không cần kỹ thuật xã hội để quản trị viên được chỉ định đi lừa đảo và đọc thư của bạn.

Và cuối cùng, người ta có thể xem xét việc áp dụng gậy bóng chày lên đầu gối là một kỹ thuật xã hội?


2
"nếu thông số kỹ thuật bị lỗi, đó không phải là lỗi" hm từ ngữ này nghe có vẻ trơn. Thay vào đó tôi sẽ nói "đó là lỗi trong thông số kỹ thuật" . Khi tôi là người kiểm tra, tôi đã gửi thành công và xác minh các bản sửa lỗi cho hàng tá lỗi như vậy. Và là một nhà phát triển, tôi đã có cơ hội sửa một số "lỗi spec" được báo cáo bởi những người thử nghiệm đối với các tài liệu API mà tôi được chỉ định để duy trì ...
gnat

8
@gnat - Tuy nhiên, "lỗi trong thông số kỹ thuật" không phải là lỗi phần mềm , đó là lỗi thiết kế . Trừ khi bạn có thể thiết kế như một phần của phần mềm. Tất cả phụ thuộc vào nơi bạn vẽ đường.
ChrisF

1
@ChrisF: Cảm ơn bạn đã nói ra những gì tôi muốn nói nhưng không biết làm thế nào. Chỉnh sửa câu trả lời để làm rõ.
SF.

Không phải lúc nào cũng rõ ràng rằng một tính năng cụ thể được ghi trong một thông số kỹ thuật là một lỗi.
Doc Brown

1
@DocBrown: Có - đôi khi cần phải giảm bảo mật khi đánh đổi hiệu suất chi phí ...
SF.

12

Cũng có thể có tình huống lỗi phần cứng gây ra vấn đề bảo mật. Chỉ cần xem xét một chip RAM bị lỗi tự động lật bit "isAdmin".

Hoặc xem xét một lỗi phần cứng giả định trong đó bảo vệ bộ nhớ không hoạt động như mong đợi và một quy trình có thể ghi đè lên bộ nhớ của quy trình khác mà không gây ra gián đoạn.

Đối với niềm vui đọc của bạn: Bảo mật máy tính bị tổn hại do lỗi phần cứng


Tỷ lệ cược cho chip RAM lật chính xác isAdmin là gì?
m3th0dman

1
Rất nhỏ, rõ ràng, nhưng nếu nó xảy ra, nó là một luồng bảo mật không phải do lỗi phần mềm.
user281377

Một cơ hội hệ thống máy tính làm hỏng các bit cho phép trên các tệp ngẫu nhiên là hoàn toàn có thể. Một tệp có thể ghi trên toàn cầu và gốc SUID có thể được chỉnh sửa một cách tầm thường để nâng cao quyền của người dùng.
SF.

@ user281377 Bạn chỉ nhận ra xác suất để chọn chính xác bit isAdmin từ tất cả các bit là 1/34359738368 cho máy có 4 GB RAM; Điều này, bỏ qua xác suất cho một lần lật chip sai.
m3th0dman

@ m3th0dman Có lẽ bạn hiểu nhầm tôi. Tôi không nói rằng đây là một vấn đề lớn mà mọi người phải quan tâm. Nó giống như một bằng chứng lý thuyết rằng một vấn đề phần cứng có thể tạo ra một luồng bảo mật. Điều đó nói rằng, có thể tưởng tượng rằng một kẻ tấn công phát hiện ra (các) bit bị lỗi trên máy chủ có thể tìm cách đệm đầu vào của mình cho đến khi một cái gì đó quan trọng được đặt vào các vị trí bộ nhớ đó.
user281377

6

Rất nhiều mối đe dọa bảo mật phát sinh từ các tính năng phần mềm, không phải lỗi. Rất nhiều tính năng phần mềm rất hữu ích hóa ra có mục đích sử dụng tốt hay xấu, chỉ phụ thuộc vào ý định của người dùng.


Phím tắt của một người là khai thác cửa sau của người khác.
Daniel Hollinrake

5

Xem xét một cuộc tấn công từ chối dịch vụ phân tán (DDOS). Đó có thể là một rủi ro bảo mật, nhưng nó không phải do lỗi phần mềm mà là do kẻ tấn công vượt quá giới hạn của những gì hệ thống được thiết kế cho. Và mọi hệ thống đều có giới hạn.

Vì vậy, câu trả lời cho câu hỏi của bạn là: không, không phải tất cả các mối đe dọa bảo mật được kích hoạt bởi lỗi phần mềm.


Nó có phải là một rủi ro bảo mật ? Nó chắc chắn có thể phá vỡ trang web của bạn nhưng nó có thể phá vỡ tính bảo mật của trang web của bạn?
Carson63000

1
Điều đó phụ thuộc vào mức độ rộng hay hẹp của định nghĩa về rủi ro bảo mật của bạn.
Pieter B

4

Kỹ thuật xã hội.

Xin chào, tôi là XX từ phòng CNTT. Máy tính của bạn hiện đang phát tán virus sang các máy tính văn phòng khác. Tôi cần tên người dùng và mật khẩu của bạn để có thể xóa nó.

Khi tin tặc đã có tên người dùng / mật khẩu, anh ta có thể cài đặt trojan một cách an toàn, v.v.

Kỹ thuật xã hội có thể được áp dụng theo nhiều cách và sử dụng nó để phá vỡ an ninh là một.


4
Một lý do có thể xảy ra, điều này không được nêu lên nhiều hơn là người hỏi đã loại trừ rõ ràng "hack xã hội".
Joachim Sauer

@JoachimSauer Điểm tốt. Không thấy điều đó.
jgauffin

3

Còn một thứ như Firesheep , addon Firefox ăn cắp cookie được truyền trên mạng không dây dùng chung thì sao?

Bạn có thể lập luận rằng lỗ hổng cho các cuộc tấn công như vậy là một lỗi, nhưng bạn cũng có thể tranh luận chống lại nó. Không có nhiều trang web có thể làm để tránh người dùng bị xâm phạm ngoài việc chạy tất cả các thông tin liên lạc qua HTTPS - bạn có thể nói rằng đó là một lỗi để chấp nhận giao tiếp HTTP trên trang web của bạn không?


1
Tôi sẽ phân loại quyết định chuyển thông tin quan trọng, riêng tư qua một phương tiện không được mã hóa thành lỗi thiết kế. Nếu điều này nên được coi là "lỗi phần mềm" là một cuộc thảo luận riêng biệt, theo ý kiến ​​của tôi.
Joachim Sauer

@JoachimSauer, điều gì sẽ xảy ra nếu trang web của bạn từ chối chuyển bất kỳ thông tin nào qua HTTP và đó thực sự là một MITM đang ánh xạ HTTP sang HTTPS? Mặc dù các trình duyệt hỗ trợ HTTP và các bộ định tuyến cho phép nó vượt qua lỗ hổng để đánh hơi mà chỉ có thể tránh được bởi các máy khách cực kỳ bảo mật. Vì vậy, thực sự câu hỏi trở thành: nó có phải là một lỗi cho trình duyệt web hỗ trợ HTTP không?
Peter Taylor

@PeterTaylor: đối với vấn đề này có HTTP Strict Transport Security , về cơ bản đảm bảo rằng trình duyệt biết rằng trang web của bạn chỉ nên được truy cập thông qua kết nối an toàn. Ngoài ra: người hỏi loại trừ rõ ràng "hack xã hội" và tùy thuộc vào người dùng bỏ qua một dòng không bảo mật có thể được coi là có trong khía cạnh đó.
Joachim Sauer

@JoachimSauer Nếu tôi chỉ ủy quyền tất cả lưu lượng truy cập vào Trang web vận chuyển nghiêm ngặt, nhưng cho phép kết nối HTTP trở lại máy khách thì sao?
Joshua Drake

@JoachimSauer: Thật vậy, tôi đồng ý với bạn. Đó là quyết định thiết kế kiến ​​trúc không khôn ngoan gây ra lỗ hổng này. Không phải bất cứ điều gì được thực thi không chính xác trong mã, đó là những gì tôi gọi là "lỗi".
Carson63000

1

Đúng vậy, trong trường hợp thất bại trong bảo mật của phần mềm là bất kể nguyên nhân nào khiến cho phần mềm bị lỗi do phần mềm thực hiện theo yêu cầu của phần mềm.

Tôi chấp nhận rằng đây chỉ là một tautology, nhưng đó là thước đo của nó.


Đôi khi bảo mật đơn giản không phải là một yêu cầu (được xác định). Và nếu nó được thêm vào danh sách các yêu cầu sau khi vi phạm an ninh, tôi sẽ không gọi đó là "lỗi".
Joachim Sauer

Chỉ vì một yêu cầu không được nêu ra khi bắt đầu một dự án, @JoachimSauer, không có nghĩa là nó không được yêu cầu. Ngành công nghiệp phần mềm đã dành thời gian dài hơn cả đời tôi để đối phó với thực tế đó.
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.