stanford-oval/wikipedia huggingface dataset:
Lỗi tràn bộ nhớ đệm
Mô tả kỹ thuật > Tràn bộ nhớ đệm trên stack

Bên cạnh việc sửa đổi các biến không liên quan, hiện tượng tràn bộ đệm còn thường bị lợi dụng (khai thác) bởi tin tặc để làm cho một chương trình đang chạy thực thi một đoạn mã tùy ý được cung cấp. Các kỹ thuật để một tin tặc chiếm quyền điều khiển một tiến trình tùy theo vùng bộ nhớ mà bộ đệm được đặt tại đó. Ví dụ, vùng bộ nhớ stack, nơi dữ liệu có thể được tạm thời "đẩy" xuống "đỉnh" ngăn xếp (push), và sau đó được "nhấc ra" (pop) để đọc giá trị của biến. Thông thường, khi một hàm (function) bắt đầu thực thi, các phần tử dữ liệu tạm thời (các biến địa phương) được đẩy vào, và chương trình có thể truy nhập đến các dữ liệu này trong suốt thời gian chạy hàm đó. Không chỉ có hiện tượng tràn stack (stack overflow) mà còn có cả tràn heap (heap overflow).
Trong ví dụ sau, "X" là dữ liệu đã từng nằm tại stack khi chương trình bắt đầu thực thi; sau đó chương trình gọi hàm "Y", hàm này đòi hỏi một lượng nhỏ bộ nhớ cho riêng mình; và sau đó "Y" gọi hàm "Z", "Z" đòi hỏi một bộ nhớ đệm lớn:
| 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 |
| --- | --- | --- | --- | --- | --- | --- | --- | --- | --- |
| Z   | Z   | Z   | Z   | Z   | Z   | Y   | X   | X   | X   |
|    |    |    |    |    |    | :   | /   | /   | /   |
Nếu hàm "Z" gây tràn bộ nhớ đệm, nó có thể ghi đè dữ liệu thuộc về hàm Y hay chương trình chính:
| 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 |
| --- | --- | --- | --- | --- | --- | --- | --- | --- | --- |
| Z   | Z   | Z   | Z   | Z   | Z   | Y   | X   | X   | X   |
| .   | .   | .   | .   | .   | .   | .   | .   | /   | /   |
Điều này đặc biệt nghiêm trọng đối với hầu hết các hệ thống. Ngoài các dữ liệu thường, bộ nhớ stack còn lưu giữ địa chỉ trả về, nghĩa là vị trí của phần chương trình đang chạy trước khi hàm hiện tại được gọi. Khi hàm kết thúc, vùng bộ nhớ tạm thời sẽ được lấy ra khỏi stack, và thực thi được trao lại cho địa chỉ trả về. Như vậy, nếu địa chỉ trả về đã bị ghi đè bởi một lỗi tràn bộ đệm, nó sẽ trỏ tới một vị trí nào đó khác. Trong trường hợp một hiện tượng tràn bộ đệm không có chủ ý như trong ví dụ đầu tiên, hầu như chắc chắn rằng vị trí đó sẽ là một vị trí không hợp lệ, không chứa một lệnh nào của chương trình, và tiến trình sẽ đổ vỡ. Tuy nhiên, một kẻ tấn công có thể chỉnh địa chỉ trả về để trỏ tới một vị trí tùy ý sao cho nó có thể làm tổn hại an ninh hệ thống.
Mô tả kỹ thuật > Mã nguồn ví dụ

Mã nguồn C dưới đây thể hiện một lỗi lập trình thường gặp. Sau khi được biên dịch, chương trình sẽ tạo ra một lỗi tràn bộ đệm nếu nó được gọi với một tham số dòng lệnh là một xâu ký tự quá dài, vì tham số này được dùng để ghi vào một bộ nhớ đệm mà không kiểm tra độ dài của nó.
/* overflow.c - demonstrates a buffer overflow */

#include <stdio.h>
#include <string.h>

int main(int argc, char *argv[])
{
 char buffer[10];
 if (argc < 2)
 {
 fprintf(stderr, "USAGE: %s string\n", argv[0]);
 return 1;
 }
 strcpy(buffer, argv[1]);
 return 0;
}
Các xâu ký tự độ dài không quá 9 sẽ không gây tràn bộ đệm. Các xâu ký tự gồm từ 10 ký tự trở lên sẽ gây tràn bộ đệm: hiện tượng này luôn luôn là một lỗi sai nhưng không phải lúc nào cũng gây ra việc chương trình chạy sai hay gây lỗi segmentation fault.
Chương trình trên có thể được viết lại cho an toàn bằng cách sử dụng hàm strncpy như sau:
#include <string.h>
#include <stdio.h>

int main(int argc, char *argv[])
{
 char buffer[10];
 if (argc < 2)
 {
 fprintf(stderr, "USAGE: %s string\n", argv[0]);
 return 1;
 }
 strncpy(buffer, argv[1], sizeof(buffer));
 buffer[sizeof(buffer) - 1] = '\0';
 return 0;
}
Khai thác

Có các kỹ thuật khác nhau cho việc khai thác lỗi tràn bộ nhớ đệm, tùy theo kiến trúc máy tính, hệ điều hành và vùng bộ nhớ. Ví dụ, khai thác tại heap (dùng cho các biến cấp phát động) rất khác với việc khai thác các biến tại stack.
Khai thác > Khai thác lỗi tràn bộ đệm trên stack

Một người dùng thạo kỹ thuật và có ý đồ xấu có thể khai thác các lỗi tràn bộ đệm trên stack để thao túng chương trình theo một trong các cách sau:
Ghi đè một biến cục bộ nằm gần bộ nhớ đệm trong stack để thay đổi hành vi của chương trình nhằm tạo thuận lợi cho kẻ tấn công.
Ghi đè địa chỉ trả về trong một khung stack (stack frame). Khi hàm trả về, thực thi sẽ được tiếp tục tại địa chỉ mà kẻ tấn công đã chỉ rõ, thường là tại một bộ đệm chứa dữ liệu vào của người dùng.
Nếu không biết địa chỉ của phần dữ liệu người dùng cung cấp, nhưng biết rằng địa chỉ của nó được lưu trong một thanh ghi, thì có thể ghi đè lên địa chỉ trả về một giá trị là địa chỉ của một opcode mà opcode này sẽ có tác dụng làm cho thực thi nhảy đến phần dữ liệu người dùng. Cụ thể, nếu địa chỉ đoạn mã độc hại muốn chạy được ghi trong một thanh ghi R, thì một lệnh nhảy đến vị trí chứa opcode cho một lệnh jump R, call R (hay một lệnh tương tự với hiệu ứng nhảy đến địa chi ghi trong R) sẽ làm cho đoạn mã trong phần dữ liệu người dùng được thực thi. Có thể tìm thấy địa chỉ của các opcode hay các byte thích hợp trong bộ nhớ tại các thư viện liên kết động (DLL) hay trong chính file thực thi. Tuy nhiên, địa chỉ của opcode đó thường không được chứa một ký tự null (hay byte 0) nào, và địa chỉ của các opcode này có thể khác nhau tùy theo các ứng dụng và các phiên bản của hệ điều hành. Dự án Metasploit là một trong các cơ sở dữ liệu chứa các opcode thích hợp, tuy rằng trong đó chỉ liệt kê các opcode trong hệ điều hành Microsoft Windows
Khai thác > Khai thác lỗi tràn bộ đệm trên heap

Bài chi tiết: Tràn heap
Một hiện tượng tràn bộ đệm xảy ra trong khu vực dữ liệu heap được gọi là một hiện tượng tràn heap và có thể khai thác được bằng các kỹ thuật khác với các lỗi tràn stack. Bộ nhớ heap được cấp phát động bởi các ứng dụng tại thời gian chạy và thường chứa dữ liệu của chương trình. Việc khai thác được thực hiện bằng cách phá dữ liệu này theo các cách đặc biệt để làm cho ứng dụng ghi đè lên các cấu trúc dữ liệu nội bộ chẳng hạn các con trỏ của danh sách liên kết. 

Lỗ hổng của Microsoft JPEG GDI+ là một ví dụ gần đây về sự nguy hiểm mà một lỗi tràn heap có thể dẫn đến.
Khai thác > Cản trở đối với các thủ thuật khai thác

Việc xử lý bộ đệm trước khi đọc hay thực thi nó có thể làm thất bại các cố gắng khai thác lỗi tràn bộ đệm. Các xử lý này có thể giảm bớt mối đe dọa của việc khai thác lỗi, nhưng có thể không ngăn chặn được một cách tuyệt đối. Việc xử lý có thể bao gồm: chuyển từ chữ hoa thành chữ thường, loại bỏ các ký tự đặc biệt (metacharacters) và lọc các xâu không chứa ký tự là chữ số hoặc chữ cái. Tuy nhiên, có các kỹ thuật để tránh việc lọc và xử lý này; alphanumeric code (mã gồm toàn chữ và số), polymorphic code (mã đa hình), Self-modifying code (mã tự sửa đổi) và tấn công kiểu return-to-libc. Cũng chính các phương pháp này có thể được dùng để tránh bị phát hiện bởi các hệ thống phát hiện thâm nhập (Intrusion detection system).
Chống tràn bộ đệm

Nhiều kỹ thuật đa dạng với nhiều ưu nhược điểm đã được sử dụng để phát hiện hoặc ngăn chặn hiện tượng tràn bộ đệm. Cách đáng tin cậy nhất để tránh hoặc ngăn chặn tràn bộ đệm là sử dụng bảo vệ tự động tại mức ngôn ngữ lập trình. Tuy nhiên, loại bảo vệ này không thể áp dụng cho mã thừa kế (legacy code), và nhiều khi các ràng buộc kỹ thuật, kinh doanh hay văn hóa lại đòi hỏi sử dụng một ngôn ngữ không an toàn. Các mục sau đây mô tả các lựa chọn và cài đặt hiện có.
Chống tràn bộ đệm > Lựa chọn ngôn ngữ lập trình

Lựa chọn về ngôn ngữ lập trình có thể có một ảnh hưởng lớn đối với sự xuất hiện của lỗi tràn bộ đệm. Năm 2006, C và C++ nằm trong số các ngôn ngữ lập trình thông dụng nhất, với một lượng khổng lồ các phần mềm đã được viết bằng hai ngôn ngữ này. C và C++ không cung cấp sẵn các cơ chế chống lại việc truy nhập hoặc ghi đè dữ liệu lên bất cứ phần nào của bộ nhớ thông qua các con trỏ bất hợp lệ; cụ thể, hai ngôn ngữ này không kiểm tra xem dữ liệu được ghi vào một mảng (cài đặt của một bộ nhớ đệm) có nằm trong biên của mảng đó hay không. Tuy nhiên, cần lưu ý rằng các thư viện chuẩn của C++, thư viện khuôn mẫu chuẩn - STL, cung cấp nhiều cách an toàn để lưu trữ dữ liệu trong bộ đệm, và các lập trình viên C cũng có thể tạo và sử dụng các tiện ích tương tự. Cũng như đối với các tính năng bất kỳ khác của C hay C++, mỗi lập trình viên phải tự xác định lựa chọn xem họ có muốn chấp nhận các hạn chế về tốc độ chương trình để thu lại các lợi ích tiềm năng (độ an toàn của chương trình) hay không.
Một số biến thể của C, chẳng hạn Cyclone, giúp ngăn chặn hơn nữa các lỗi tràn bộ đệm bằng việc chẳng hạn như gắn thông tin về kích thước mảng với các mảng. Ngôn ngữ lập trình D sử dụng nhiều kỹ thuật đa dạng để tránh gần hết việc sử dụng con trỏ và kiểm tra biên do người dùng xác định.
Nhiều ngôn ngữ lập trình khác cung cấp việc kiểm tra tại thời gian chạy, việc kiểm tra này gửi một cảnh báo hoặc ngoại lệ khi C hoặc C++ ghi đè dữ liệu. Ví dụ về các ngôn ngữ này rất đa dạng, từ Python tới Ada, từ Lisp tới Modula-2, và từ Smalltalk tới OCaml. Các môi trường bytecode của Java và .NET cũng đòi hỏi kiểm tra biên đối với tất cả các mảng. Gần như tất cả các ngôn ngữ thông dịch sẽ bảo vệ chương trình trước các hiện tượng tràn bộ đệm bằng cách thông báo một trạng thái lỗi định rõ (well-defined error). Thông thường, khi một ngôn ngữ cung cấp đủ thông tin về kiểu để thực hiện kiểm tra biên, ngôn ngữ đó thường cho phép lựa chọn kích hoạt hay tắt chế độ đó. Việc phân tích tĩnh (static analysis) có thể loại được nhiều kiểm tra kiểu và biên động, nhưng các cài đặt tồi và các trường hợp rối rắm có thể giảm đáng kể hiệu năng. Các kỹ sư phần mềm phải cẩn thận cân nhắc giữa các phí tổn cho an toàn và hiệu năng khi quyết định sẽ sử dụng ngôn ngữ nào và cấu hình như thế nào cho trình biên dịch.
Chống tràn bộ đệm > Sử dụng các thư viện an toàn

Vấn đề tràn bộ đệm thường gặp trong C và C++ vì các ngôn ngữ này để lộ các chi tiết biểu diễn mức thấp của các bộ nhớ đệm với vai trò các chỗ chứa cho các kiểu dữ liệu. Do đó, phải tránh tràn bộ đệm bằng cách gìn giữ tính đúng đắn cao cho các phần mã chương trình thực hiện việc quản lý bộ đệm. Việc sử dụng các thư viện được viết tốt và đã được kiểm thử, dành cho các kiểu dữ liệu trừu tượng mà các thư viện này thực hiện tự động việc quản lý bộ nhớ, trong đó có kiểm tra biên, có thể làm giảm sự xuất hiện và ảnh hưởng của các hiện tượng tràn bộ đệm. Trong các ngôn ngữ này, xâu ký tự và mảng là hai kiểu dữ liệu chính mà tại đó các hiện tượng tràn bộ đệm thường xảy ra; do đó, các thư viện ngăn chặn lỗi tràn bộ đệm tại các kiểu dữ liệu này có thể cung cấp phần chính của sự che chắn cần thiết. Dù vậy, việc sử dụng các thư viện an toàn một cách không đúng có thể dẫn đến tràn bộ đệm và một số lỗ hổng khác; và tất nhiên, một lỗi bất kỳ trong chính thư viện chính nó cũng là một lỗ hổng. Các cài đặt thư viện "an toàn" gồm The Better String Library, Arri Buffer API và Vstr. Thư viện C của hệ điều hành OpenBSD cung cấp các hàm hữu ích strlcpy strlcat, nhưng các hàm này nhiều hạn chế hơn nhiều so với các cài đặt thư viện an toàn đầy đủ.
Tháng 9 năm 2006, Báo cáo kỹ thuật số 24731 của hội đồng tiêu chuẩn C đã được công bố; báo cáo này mô tả một tập các hàm mới dựa trên các hàm vào ra dữ liệu và các hàm xử lý xâu ký tự của thư viện C chuẩn, các hàm mới này được bổ sung các tham số về kích thước bộ đệm.
Chống tràn bộ đệm > Chống tràn bộ nhớ đệm trên stack

Bài chi tiết: Stack-smashing protection
Stack-smashing protection là kỹ thuật được dùng để phát hiện các hiện tượng tràn bộ đệm phổ biến nhất. Kỹ thuật này kiểm tra xem stack đã bị sửa đổi hay chưa khi một hàm trả về. Nếu stack đã bị sửa đổi, chương trình kết thúc bằng một lỗi segmentation fault. Các hệ thống sử dụng kỹ thuật này gồm có Libsafe, StackGuard  và các bản vá lỗi (patch) ProPolice gcc.
Chế độ Data Execution Prevention (cấm thực thi dữ liệu) của Microsoft bảo vệ thẳng các con trỏ tới SEH Exception Handler, không cho chúng bị ghi đè.
Có thể bảo vệ stack hơn nữa bằng cách phân tách stack thành hai phần, một phần dành cho dữ liệu và một phần cho các bước trả về của hàm. Sự phân chia này được dùng trong ngôn ngữ lập trình Forth, tuy nó không phải một quyết định thiết kế dựa theo tiêu chí an toàn. Nhưng dù sao thì đây cũng không phải một giải pháp hoàn chỉnh đối với vấn đề tràn bộ đệm, khi các dữ liệu nhạy cảm không phải địa chỉ trả về vẫn có thể bị ghi đè.
Chống tràn bộ đệm > Bảo vệ không gian thực thi

Bài chi tiết: Bảo vệ không gian thực thi
Bảo vệ không gian thực thi là một cách tiếp cận đối với việc chống tràn bộ đệm. Kỹ thuật này ngăn chặn việc thực thi mã tại stack hay heap. Một kẻ tấn công có thể sử dụng tràn bộ đệm để chèn một đoạn mã tùy ý vào bộ nhớ của một chương trình, nhưng với bảo vệ không gian thực thi, mọi cố gắng chạy đoạn mã đó sẽ gây ra một ngoại lệ (exception).
Một số CPU hỗ trợ một tính năng có tên bit NX ("No eXecute" - "Không thực thi") hoặc bit XD ("eXecute Disabled" - "chế độ thực thi đã bị tắt"). Khi kết hợp với phần mềm, các tính năng này có thể được dùng để đánh dấu các trang dữ liệu (chẳng hạn các trang chứa stack và heap) là đọc được nhưng không thực thi được.
Một số hệ điều hành Unix (chẳng hạn OpenBSD, Mac OS X) có kèm theo tính năng bảo vệ không gian thực thi (ví dụ W^X). Một số gói phần mềm tùy chọn bao gồm:
PaX
Exec Shield
Openwall
Các biến thể mới của Microsoft Windows cũng hỗ trợ bảo vệ không gian thực thi, với tên gọi Data Execution Prevention (ngăn chặn thực thi dữ liệu). Các phần mềm gắn kèm (Add-on) bao gồm:
SecureStack
OverflowGuard
BufferShield
StackDefender
Phương pháp bảo vệ không gian thực thi không chống lại được tấn công return-to-libc.
Chống tràn bộ đệm > Ngẫu nhiên hóa sơ đồ không gian địa chỉ

Bài chi tiết: Ngẫu nhiên hóa sơ đồ không gian địa chỉ
Ngẫu nhiên hóa sơ đồ không gian địa chỉ (Address space layout randomization - ASLR) là một tính năng an ninh máy tính có liên quan đến việc sắp xếp vị trí các vùng dữ liệu quan trọng (thường bao gồm nơi chứa mã thực thi và vị trí các thư viện, heap và stack) một cách ngẫu nhiên trong không gian địa chỉ của một tiến trình.
Việc ngẫu nhiên hóa các địa chỉ bộ nhớ ảo mà các hàm và biến nằm tại đó làm cho việc khai thác một lỗi tràn bộ đệm trở nên khó khăn hơn, nhưng không phải là không thể được. Nó còn buộc kẻ tấn công phải điều chỉnh khai thác cho hợp với từng hệ thống cụ thể, điều này làm thất bại cố gắng của các con sâu Internet. Một phương pháp tương tự nhưng kém hiệu quả hơn, đó là kỹ thuật rebase đối với các tiến trình và thư viện trong không gian địa chỉ ảo.
Chống tràn bộ đệm > Kiểm tra sâu đối với gói tin

Bài chi tiết: Deep packet inspection
Biện pháp kiểm tra sâu đối với gói tin (deep packet inspection - DPI) có thể phát hiện các cố gắng từ xa để khai thác lỗi tràn bộ đệm ngay từ biên giới mạng. Các kỹ thuật này có khả năng chặn các gói tin có chứa chữ ký của một vụ tấn công đã biết hoặc chứa một chuỗi dài các lệnh No-Operation (NOP - lệnh rỗng không làm gì), các chuỗi như vậy thường được sử dụng khi vị trí của nội dung quan trọng (payload) của tấn công hơi có biến đổi.
Việc rà các gói tin không phải là một phương pháp hiệu quả vì nó chỉ có thể ngăn chặn các tấn công đã biết, và có nhiều cách để mã hóa một lệnh NOP. Các kẻ tấn công có thể đã sử dụng mã alphanumeric, metamorphic, và shellcode tự sửa để tránh bị phát hiện bởi việc rà gói tin.
Thực hiện thao tác khởi động lại
Lịch sử khai thác

Khai thác lỗi tràn bộ đệm được biết đến đầu tiên là vào năm 1988. Đó là một trong các khai thác mà sâu Morris sử dụng để lan truyền chính mình trên Internet. Chương trình đã bị khai thác là một dịch vụ Unix có tên fingerd.
Sau đó, vào năm 1995, Thomas Lopatic đã tái phát hiện hiện tượng tràn bộ đệm một cách độc lập và công bố phát kiến của mình trên danh sách thư an ninh Bugtraq. Một năm sau, 1996, Elias Levy (còn gọi là Aleph One) công bố trên tạp chí Phrack bài báo "Smashing the Stack for Fun and Profit" (Phá bộ nhớ stack cho vui và để thu lợi),, đây là một hướng dẫn từng bước cho việc khai thác các lỗ hổng tràn bộ đệm trên stack.
Từ đó, ít nhất hai con sâu Internet đã khai thác lỗi tràn bộ đệm để xâm phạm hàng loạt hệ thống lớn. Năm 2001, Sâu Code Red khai thác lỗi tràn bộ đệm trong chương trình Internet Information Services (IIS) 5.0 của Microsoft, và vào năm 2003, sâu SQLSlammer đã phá hoại các máy chạy Microsoft SQL Server 2000.
Chú thích

1 2  Safer C: Developing Software for High-integrity and Safety-critical Systems (ISBN 0-07-707640-0)
↑  “The Metasploit Opcode Database”. Bản gốc lưu trữ ngày 12 tháng 5 năm 2007. Truy cập ngày 9 tháng 10 năm 2006.
↑  Microsoft Technet Security Bulletin MS04-028
↑  Libsafe at FSF.org
↑  (PDF) StackGuard: Automatic Adaptive Detection and Prevention of Buffer-Overflow Attacks by Cowan et al.
↑  “ProPolice at X.ORG”. Bản gốc lưu trữ ngày 12 tháng 2 năm 2007. Truy cập ngày 9 tháng 10 năm 2006.
↑  Bypassing Windows Hardware-enforced Data Execution Prevention
↑  PaX: Trang nhà của nhóm PaX
↑  “KernelTrap.Org”. Bản gốc lưu trữ ngày 29 tháng 5 năm 2012. Truy cập ngày 29 tháng 5 năm 2012.
↑  “Microsft Technet: Data Execution Prevention”. Bản gốc lưu trữ ngày 22 tháng 6 năm 2006. Truy cập ngày 9 tháng 10 năm 2006.
↑  BufferShield: Prevention of Buffer Overflow Exploitation for Windows[liên kết hỏng]
↑  PaX at GRSecurity.net
↑  “"A Tour of The Worm" by Donn Seeley, University of Utah”. Bản gốc lưu trữ ngày 20 tháng 5 năm 2007. Truy cập ngày 9 tháng 10 năm 2006.
↑  “Bugtraq security mailing list”. Bản gốc lưu trữ ngày 1 tháng 9 năm 2007. Truy cập ngày 9 tháng 10 năm 2006.
↑  “"Smashing the Stack for Fun and Profit" by Aleph One”. Bản gốc lưu trữ ngày 1 tháng 5 năm 2007. Truy cập ngày 9 tháng 10 năm 2006.
↑  eEye Digital Security
↑  Microsft Technet Security Bulletin MS02-039
Codonoblepharum heterophyllum

| Codonoblepharum heterophyllum> Phân loại khoa học |
| --- | --- |
Giới (regnum): Plantae
Ngành (divisio): Bryophyta
Lớp (class): Bryopsida
Bộ (ordo): Pottiales
Họ (familia): Calymperaceae
Chi (genus): Codonoblepharum
Loài (species): C. heterophyllum
Danh pháp hai phần
Codonoblepharum heterophyllum Mitt. Müll. Hal., 1900 
Codonoblepharum heterophyllum là một loài rêu trong họ Calymperaceae. Loài này được Mitt. Müll. Hal. mô tả khoa học đầu tiên năm 1900.
Chú thích

↑  The Plant List (2010). “Codonoblepharum heterophyllum”. Truy cập ngày 31 tháng 5 năm 2014.
Coccoloba lundellii

| Coccoloba lundellii> Phân loại khoa học |
| --- | --- |
Giới (regnum): Plantae
(không phân hạng): Angiospermae
(không phân hạng): Eudicots
Bộ (ordo): Caryophyllales
Họ (familia): Polygonaceae
Chi (genus): Coccoloba
Loài (species): C. lundellii
Danh pháp hai phần
Coccoloba lundellii Standl., 1930 
Coccoloba lundellii là một loài thực vật có hoa trong họ Rau răm. Loài này được Standl. mô tả khoa học đầu tiên năm 1930.
Chú thích

↑  The Plant List (2010). “Coccoloba lundellii”. Truy cập ngày 19 tháng 9 năm 2013.
Cnemolia albicollis

| Cnemolia albicollis> Phân loại khoa học |
| --- | --- |
Giới (regnum): Animalia
Ngành (phylum): Arthropoda
Lớp (class): Insecta
Bộ (ordo): Coleoptera
Phân bộ (subordo): Polyphaga
Liên họ (superfamilia): Cerambycoidea
Họ (familia): Cerambycidae
Chi (genus): Cnemolia
Loài (species): C. albicollis
Danh pháp hai phần
Cnemolia albicollis Breuning, 1969 
Cnemolia albicollis là một loài bọ cánh cứng trong họ Cerambycidae.
Chú thích

↑  Bisby, F.A.; Roskov, Y.R.; Orrell, T.M.; Nicolson, D.; Paglinawan, L.E.; Bailly, N.; Kirk, P.M.; Bourgoin, T.; Baillargeon, G.; Ouvrard, D. (2011). “Species 2000 & ITIS Catalogue of Life: 2011 Annual Checklist”. Species 2000: Reading, UK. Truy cập ngày 24 tháng 9 năm 2012.
Coelichneumon pervagus

| Coelichneumon pervagus> Phân loại khoa học |
| --- | --- |
Giới (regnum): Animalia
Ngành (phylum): Arthropoda
Lớp (class): Insecta
Bộ (ordo): Hymenoptera
Họ (familia): Ichneumonidae
Chi (genus): Coelichneumon
Loài (species): C. pervagus
Danh pháp hai phần
Coelichneumon pervagus (Cresson, 1877) 
Coelichneumon pervagus là một loài tò vò trong họ Ichneumonidae.
Chú thích

↑  Bisby, F.A.; Roskov, Y.R.; Orrell, T.M.; Nicolson, D.; Paglinawan, L.E.; Bailly, N.; Kirk, P.M.; Bourgoin, T.; Baillargeon, G.; Ouvrard, D. (2011). “Species 2000 & ITIS Catalogue of Life: 2011 Annual Checklist”. Species 2000: Reading, UK. Truy cập ngày 22 tháng 6 năm 2014.
Colocleora tichomecha

| Colocleora tichomecha> Phân loại khoa học |
| --- | --- |
Giới (regnum): Animalia
Ngành (phylum): Arthropoda
Lớp (class): Insecta
Bộ (ordo): Lepidoptera
Họ (familia): Geometridae
Chi (genus): Colocleora
Loài (species): C. tichomecha
Danh pháp hai phần
Colocleora tichomecha Prout 1935 
Colocleora tichomecha là một loài bướm đêm trong họ Geometridae.
Chú thích

↑  Bisby, F.A.; Roskov, Y.R.; Orrell, T.M.; Nicolson, D.; Paglinawan, L.E.; Bailly, N.; Kirk, P.M.; Bourgoin, T.; Baillargeon, G.; Ouvrard, D. (2011). “Species 2000 & ITIS Catalogue of Life: 2011 Annual Checklist”. Species 2000: Reading, UK. Truy cập ngày 24 tháng 9 năm 2012.
Chuyến bay 642 của China Airlines

| --- | --- |
Chiếc MD-11 trong vụ tai nạn khi vẫn đang hoạt động cho Mandarin Airlines năm 1998
Tai nạn
Ngày: 22 tháng 8 năm 1999
Mô tả tai nạn: Lỗi phi công
Địa điểm: Sân bay quốc tế Hồng Kông
Máy bay
Dạng máy bay: McDonnell Douglas MD-11
Hãng hàng không: China Airlines/Mandarin Airlines
Số đăng ký: B-150
Xuất phát: Sân bay quốc tế Don Mueang
Chặng dừng: Sân bay quốc tế Hồng Kông
Điểm đến: Sân bay quốc tếChiang Kai-shek
Hành khách: 300
Phi hành đoàn: 15
Tử vong: 3
Bị thương: 208 (44 nặng, 164 nhẹ)
Sống sót: 312
Sơ đồ chỗ ngồi
Chuyến bay 642 của China Airlines (CI642/CAL642) là chuyến bay đã đâm xuống đường băng sân bay quốc tế Hồng Kông vào ngày 22 tháng 8 năm 1999. Chuyến bay xuất phát từ Bangkok (Sân bay quốc tế Bangkok, nay là Sân bay quốc tế Don Mueang) đến Đài Bắc, quá cảnh tại Hồng Kông.
Chiếc máy bay khai khác đường bay này là McDonnell Douglas MD-11, điều hành bởi Mandarin Airlines, công ty con của China Airlines. Khi cố gắng hạ cánh trong cơn bão, chiếc máy bay tiếp đất rất mạnh, bị lật ngược và bắt lửa. Trong số 315 hành khách trên máy bay, ba người thiệt mạng và 312 người sống sót.
Chuyến bay này vẫn tiếp tục được khai thác bằng máy bay Boeing 747-400 và Airbus A330-300 cho đến ngày nay, tuy không còn xuất phát từ Bangkok, và chỉ còn là chuyến bay nối Hồng Kông với Đài Bắc. Đường bay Bangkok – Hồng Kông đã ngừng khai thác từ ngày 31 tháng 10 năm 2010.
Chuyến bay 642 là một trong hai vụ tai nạn khiến chiếc máy bay MD-11 với cấu hình chở khách bị hư hại ngoài khả năng sửa chữa, vụ còn lại là Chuyến bay 111 của Swissair. Tất cả những vụ tai nạn mất thân khác của loại máy bay này đều liên quan đến phiên bản chở hàng của nó.
Diễn biến

Khoảng 6:43 chiều giờ địa phương (10:43 UTC) ngày 22 tháng 8 năm 1999, chiếc máy bay McDonnell Douglas MD-11 mang số hiệu B-150 đang chuẩn bị hạ cánh xuống đường băng 25L của sân bay quốc tế Hồng Kông. Trong lúc đó, bão Sam đang ở cách sân bay 50 km về hướng đông bắc. Khi ở độ cao 700 feet (200 m), tổ bay nhận được thông báo sức gió ở mức 320 độ/28 knot, gió giật 36 knot. Điều này khiến máy bay đi vào vùng gió ngược có sức gió 21,4 knot giật 27,5 knot, trong khi sức gió giới hạn của máy bay là ở 35 knot. Khi máy bay chuẩn bị tiếp đất, chiếc máy bay nghiêng sang phải, tiếp đất rất mạnh trên càng hạ cánh phải và động cơ số ba va chạm với mặt đất. Cánh bên phải gãy rời khỏi thân máy bay. Chiếc máy bay tiếp tục lăn vòng và trượt khỏi đường băng, bốc cháy. Khi nó dừng lại, trần máy bay chạm đất, nằm cách giới hạn đường băng 1.100 m. Cánh phải máy bay nằm trên một đường lăn cách mũi máy bay 90 m. Lửa làm phần sau máy bay hư hại nặng nhưng cũng nhanh chóng bị dập tắt nhờ cơn mưa lớn và phản ứng nhanh chóng của đội cứu hộ sân bay.
Trong số 315 người có mặt trên máy bay, 3 hành khách thiệt mạng. Toàn bộ 15 nhân viên phi hành đoàn sống sót.